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IMPORTANT NOTICES 


Texas Instruments reserves the right to make changes at any time to 


improve design and to supply the best posible product for the spectrum 
of users. 


Microprocessor Pascal System (TMSW753P or TMSW754P) is copyrighted by 
Texas Instruments Incorporated, and is sole property thereof. Use of 
this product is defined by the license agreement SC-1l between the 
customer and Texas Instruments. The software may not be reproduced in 
any form without written permission of Texas Instruments. However, 
application run-time packages generated from the Microprocessor Pascal 


System may be reproduced for resale exclusively by the customer — 


purchasing the Microprocessor Pascal System. 


All manuals associated with Microprocessor Pascal (MP35l1) are printed 
in the United States of America and are copyrighted by Texas 
Instruments Incorporated, all rights reserved. No part of these 
publications may be reproduced in any manner, including storage in a 
retrieval system or transmittal via electronic means, or other 
reproduction in any form or by any method (electronic, mechanical, 
photocopying, recording, Or otherwise) without prior written 
permission of Texas Instruments Incorporated. | | 


Information contained in these publications is believed to be accurate 
and reliable. However, responsibility is neither assumed for its use, 
nor for any infringement of patents or rights that may result from its 
use. No license is granted by implication or otherwise under any 
patent or patent right of Texas Instruments or others. 
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SECTION I 


OVERVIEW 


1.1 GENERAL 


The Realtime Executive (Rx) is a standalone executive designed to 
support software applications executing on the 9900 family of 
microprocessors. The information in this manual is’ specifically 
oriented toward the assembly language user; the Microprocessor Pascal 
System User”s Guide describes the MPP interface to Rx.) 


A software environment denotes software constructs, routines, 
structures and all associated data and related software that permit 
system operation. The environment normally familiar to the assembly 
language programmer supports a single program executing sequentially. 
This program has the undivided attention of the central processor; it 
runs from beginning to end without interruption. Rx, however, supports 
multiprogramming. Independent sites of execution (processes) exist 
within a single environment and share a single processor. E-ecution of 
one process may be interrupted by the executive when another, more 
urgent, process is ready to execute. There are various constructs 
within Rx which support multiprogramming and automatically participate 
in helping the user application to run. 


Rx can be thought of as a "configurable" executive; a "do it yourself" 
kit that allows the user to build an executive to fit user application 
needs by allowing selection of only those modules needed to execute 
the task at hand. The user can also take advantage of a variety of 
data structures and routines supplied by the executive which are 
usually not available to the low-level language application 
programmer. These routines support concurrency and reentrancy in code. 


This section introduces the user to the Realtime Executive, its 
features and benefits. Section 2 discusses the Rx concepts that are 
necessary for the user to understand in order to use the product, 
while Section 3 builds on that information to enable the user to write 
an Rx routine. In addition, an example, "DEMOPGM" is offered to give 
the Rx user some early "hands-on" experience. Standard Rx routines are 
listed and explained in Section 4, with pertinent examples, while Rx 
Channel routines are detailed in Section 5. The configuration of the 
target system and creation of an object code load module are covered 
in Section 6. Target debugging explanations are provided for both the 


- Rx Standalone Debugger (Section 7), and the AMPL Debugger (Section 8). 


The codes and remedial actions, routine templates, size breakdown, and 
assembler listing and link map for the Demo Program. 
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1.2 PRODUCT FEATURES 


Short descriptions of the features available in RX are presented 


below: 


Oo Processor Management (including concurrent process 
execution with preemptive priority scheduling) 


Oo Interrupt processing and control 


oO Memory Management (including Stack and Heap 
management) 


Oo Inter-process communication capability 

O Real-time clock servicing 

o Semaphore creation/management 

Oo Dynamic process creation - 

Oo Operator communications input/output 

© Debugger support 

o Configurability (to conserve memory requirements) 

O Reentrancy in code 

o Compatibility with Texas Instruments” device 

independent I/O Subsystems 

1.3 RX AS THE DRIVER OF COMPONENT SOFTWARE 
Rx is associated with the Texas Instruments” 9900 family of 
component software. This family consists of a variety of 
individual software products that can be separately purchased and 
linked to the user”’s application. 
Compatible with the spectrum of Texas Instruments” component 
software, Rx acts like a software bus, "driving" the application. 
Various component pieces such as Texas Instruments” Math Package, 


File Manager, and Data Communications packages can be added and 
used in the application. (Because of the modularity of the 


routines comprising these products, the load module produced to. 


run on a target will include only those "pieces" of the component 
that are required by the application.) 


1.4 AN Rx APPLICATION 


Although several concepts will be new to some users, a_ simple 
example can be used to illustrate the benefits of Rx. Consider a 
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factory that needs a system to control both a manufacturing 
process and an accounting department. This factory has a 
TM990/101M CPU with a TM990/206 memory board and a TM990/305 I/0 
board. Within the factory, many machines must be controlled 
simultaneously, some interrelated and some not (see Figure 1-1). 
A standard operating system approach to control these many 
machines would be hard to implement and inefficient to use. A 
better way to approach the problem of control involves writing a 
separate piece of code for every machine process, each executing 
as required. Communication between these processes is necessary 
to ensure that each separate step associated with the manufacture 
of a product and the keeping of factory books is carried out 
within the correct time frame. A modular executive that supports 
multiprogramming will ease such software design. Rx supplies all 
of these executive features. 


RECEIVABLE manele . aaaeow | 


(LEVEL 2) | ACCOUNTING | 


“SYSTEM | FACTURING |. —_— 
TEST 


(LEVEL 2) 





pee (LEVEL ¢) TEGeR a 





ACCOUNTS a 
PAYABLE | PACKAGE| 
(LEVEL 2) . — (LEVEL 2)! | | 


FIGURE 1-1. EXAMPLE OF Rx CONTROL OF A FACTORY SYSTEM. 


1.5 Rx I/O SUBSYSTEMS 


RX supports Texas Instruments* File I/O Decoder which provides 
the means for the user to initiate and execute device-independent 


(file) I/0. 
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Use of the I/O subsystem enables communication with and 
manipulation of data to and from various locations regardless of 
the media on which the data resides. | 


For more detailed information regarding file I/O, refer to the 
Device Independent File I/O User”“s Manual, MP386. 

1.6 REFERENCE MATERIALS | 

the following Texas Instruments publications were used in the 
development of this manual, and provide additional information 


relative to Rx and to related TI software. 


THE SOFTWARE DEVELOPMENT HANDBOOK, MPA29 


- THE FILE MANAGER USER’S MANUAL, MMP355 


- MODEL 990 COMPUTER TMS9900 MICROPROCESSOR ASSEMBLY LANGUAGE 


PROGRAMMER’S GUIDE, 943441-9701 


- AMPL MICROPROCESSOR PROTOTYPING LABORATORY OPERATION GUIDE, 


946275-9701%*A 


- 9900 FMILY SYSTEMS DESIGN AND DATA BOOK, LCC4400, 97049-118-NI 


- THE MICROPROCESSOR PASCAL SYSTEM USER“S MANUAL, MP351 


- DEVICE INDEPENDENT FILE I/O USER°S MANUAL, MP386 














SECTION 2 


Rx CONCEPTS 


2.1 GENERAL 


Understanding the concepts used and supported by Rx is a necessary 
prerequisite for understanding the product itself. Rx software 
Organization is discussed in subsection 2.2 and descriptions of 
procedures, functions, processes and systems in the Rx environment are 
given. Subsection 2.3 will deal with the concept of concurrency, 
Priority scheduling, semaphores and interrupts. Memory organization 
using stacks and heaps and a discussion of system initialization. 
Understanding the Rx terms and concepts in this section is necessary 
in order to understand Rx module construction. Templates are provided 


in Appendix C. 


2.2 SOFTWARE ORGANIZATION 


In RX, user applications are built using a collection of processes 
nested at different levels in a system. These levels are referred to 
as “lexical levels" and indicate to Rx the level at which a process is 
embedded within the system. Figure 2-1 depicts this concept: 


As the figure indicates, the system is found at lexical level 0, with 
those processes that the system starts residing at level l. Any 
process called in the course of these (Level 1) processes” execution 
will be assigned level 2 or lower. A process that starts any other 
Process is referred to as that process” lexical "parent", and _ the 
called process is referred to as the "Spawn". These processes are 
composed of functional units referred to as procedures and functions. 


PROCESS PROC1; = LEVEL2 =< 


BEGIN (PROCESS BODY) 
END; 


8EGIN (PROGRAM BODY) 
END; 





PROCESS PROC2A; =—= LEVEL3 


BEGIN (PROCESS BOOY) 
ENO: 


BEGIN (PROCESS BOOY) 
ENO; 


PROCESS PROC3; == LEVEL2 


BEGIN (PROCESS BODY) 
ENO; 


BEGIN (PROGRAM 8BOOY) 
ENO; 





BEGIN (SYSTEM BODY) 
ENO: 


FIGURE 2-1. THE NESTING CONCEPT. 


2.2.1. System 


The System, designated by the SYSTMS label, is a special case of a 
process within which all other modules are contained; it is the 
outermost level of executable statements in the Rx environment. The 
System usually starts the other processes contained within it. Only 
one System can exist in the Rx environment at any one time, and all 
global data is defined within it. Occupying lexical level 9, those 
processes nested in the System reside at levels 1, 2, 3, and so on. 
When started, the: system is allocated all available memory (or less if 
it asks for less in the heapsize parameter to S$PRCS) which becomes 
the system heap (subsection 2.4.2). It is from this parent heap that 
subsequent allocations of stack and heap, when needed, are made to 
Starting processes. The System, then, may be thought of as the process 
in which execution begins. | | 


ae eae 
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2.2.2 Program Process 


A special case of process, an RX program resides only at lexical level 
1, and therefore cannot call another program. A program’s’ lexical 
parent is always the System. 


2.2.3 Process 


Residing at lexical level 1 or lower, a process is a collection of 
procedures, functions, and data which perform an independent operation 
concurrently with the scheduling and execution of other processes. 
Analogous to a "task" in IBM’s 0OS370, it is independently scheduled 
and may interact with other processes or with the executive as 
necessary during execution... Note that processes may be created by 
other processes. 


An Rx process is defined in terms of its three component parts: a) the 
process code, b) the process data, and c) the process’ record. 
Processes differ from procedures or functions in that they are 
independently scheduled by the executive, and are executed in a 
concurrent fashion. A process will execute until it reaches a point 
where either required data is needed, a higher priority process 
becomes ready for execution, or the process simply completes. When 
control is switched from a process, the current state of the process 
is "saved" in the associated process record. 


The process record itself is an area of memory dynamically allocated 
from the parent heap (subsection 2.4.1) when the process is started 
(i.e., performs a call.to S$PRCS), and will be located wherever memory 
is available when it is started. In addition to the status of the 
current process, the record also contains the process priority, a 
pointer to the stack and other data required to schedule and execute 
the process. (Reference Appendix A for the structure of a process 
record.) 


The executive uses the information contained in the process record to 
schedule. For “ready” processes (subsection 2.3), a queue of pointers 
to process records is maintained. The priority of a process determines 
its place in this queue. (Subsection 2.3.1 discusses priorities and 
priority scheduling of processes.) 


2.2.4 Procedure 


Functional units of code can be isolated into separate modules’ called 
procedures. Similar to a subroutine in FORTRAN, PASCAL or BASIC, 
procedures are computer software design constructs used to associate 
sequences of low-level processing steps by the higher-level function 
they perform. A procedure is included in a process code section by 
virtue of being invoked (called) by a single instruction from either 
the process code section, or some other procedure which has_ been 
called by the process code section. When execution of the procedure 
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has completed, control returns to the calling routine at the 
instruction following the call. ; 


When a procedure is called, an area of memory referred to as a "stack 
frame" is assigned for that procedure’s workspace from the "stack" of 
the calling process. (See subsection 2.4 for more information on 
stacks and stack frames.) The size of the assigned memory is a 
function of the value specified by the stackframe size set in the 
beginning section of the procedure template (refer to Appendix C, 
subsection C.3). 


2.2.5 Function 


Functions are composed of a set of instructions that, like procedures, 
can be called by a single instruction in a process. Procedures and 
functions are similar with the exception that a function will 
generally return a result upon its completion. (An Rx function can be 
likened to the FORTRAN function.) 


2.3 CONCURRENCY 


The Rx environment supports the execution of several processes 
concurrently. Although it appears to the user that these processes are 
executing at the same time, execution is actually moving from one to 
another as CPU time is shared on a process’ priority basis. The 
execution of several processes in the same system is’ termed 
"multiprogramming". Each process in the Rx environment is in one of 
three states: 


1) Active 
2) Ready to execute 


3) Suspended (blocked) and waiting for a condition in the 
system to change (an event’ to occur) before it can 
become ready to execute. 


The executing process resides in the active queue. Processes that 
are ready to execute reside ina ready (or scheduling) queue. 
Processes that are suspended and waiting for an event to occur 
are placed in another queue associated with the event until 
notified that an event has taken place. This notification will 
come via information supplied by a "semaphore" (simply thought of 
as an event flag). Semaphores are signaled of events by other 
processes or interrupts. These three features (prioritized 
scheduling, ‘semaphores, and interrupts) are tools used by Rx to 
Support concurrency. They are described in more detail in the 
following subsections. 














2.3.1 Priority Scheduling 


The Rx scheduling policy determines the assignment of the 
processor to one of the ready processes. Ready processes are 
inserted into the ready queue and scheduled for execution 
according to priority. | 


A process” priority is represented by a user-assigned numeric 
value. The greatest urgency is represented by 0; the least by 
32767, which is reserved for the IDLE process. (IDLE is active 
only when all other processes in the system are blocked.) 
Priority values 0 to 15 indicate device processes associated with 
interrupts. Interrupts occur due to a change in some "real world" 
condition or because they are programmed to occur. Priority 
values 16 TO 32766 represent non-device processes. 


A scheduling decision is made by Rx each time a suspended process 
becomes ready or the currently executing process terminates or 
becomes suspended. (An explanation of process readiness’ follows 
this discussion of scheduling.) When the active process 
terminates execution (or becomes suspended) the first process in 
the ready queue becomes’ the active process. Because the ready 
queue is ordered by priority, the most urgent process that is 
ready is given the processor. When a suspended process becomes 
ready, it is inserted in the ready queue based on its priority. 
The newly-ready process preempts' the currently active process 
(i-e., is placed in it’s place in the active queue) if it is more 
urgent. Non-device processes that become ready are placed in the 
queue behind processes of equal priority. This ensures that when 
two processes have equal priority, the process that has’ been 
ready the longest executes first. Device processes are placed in 
front of other processes of equal priority including the active 
process. Figure 2-2 illustrates the working of this scheduling 
policy. 


The first column contains the active process. The ready queue is 
represented as a horizontal series of boxes behind the active 
process. Each process (box) is labeled with a letter and a 
priority number. The first box in the ready queue is the active 
process. Time moves vertically from top to bottom. Comments’ to 
the right of each queue describe the action performed. 
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FIGURE 2-2. SCHEDULING POLICY. 


The execution of Rx scheduling policy displayed in Figure 2-2 
results in process "B" never becoming active. In fact, B will 
never become active unless all other processes in queue with 
greater urgency become blocked or terminate execution. A process 
of higher urgency that becomes ready will always interrupt the 
(Currently) active process. Once the more urgent process 
terminates (or becomes blocked) the previously active process 
will resume execution (unless another higher priority process 
become ready). This "preemptive scheduling with resumption” is 
designed for event-driven systems in which the event is some 
real-world occurrence that demands the immediate attention of the 
processor. 


Up to this point, the discussion has been concerned with the 
management of processes that are ready for execution. However, 
Processes may become suspended or blocked because of a condition 
in the system. When another process signals that the condition 
has changed, the waiting process can become ready. The mechanics 
Of this process synchronization are described in the next 
section. 
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2.3.2 SEMAPHORES 


The semaphore is the fundamental mechanism for synchronization of 
processes via Rx, and can be thought of as representing some 
event on which processes synchronize. A process’ which is 
dependent on the occurence of an event can perform a WAIT 
operation to ensure that the event has occurred before continuing 
execution. If the event has already occurred, the process 
executes; if not, the process is suspended in that semaphores 
queue until the event does occur. A SIGNAL operation performed on 
the associated semaphore allows a process to signal the occurence 
of an event. If some process is waiting for the event, it is made 
ready for execution by removing it from that semaphore”s queue 
and inserted into the ready (or “scheduling”~) queue. If no 
process is waiting, the occurrence of the event is recorded in 
the semaphore until a WAIT operation occurs for that event. 


The semaphores of Rx can be thought of as "counting" semaphores 
in that an occurence of an event is never lost, even if no 
process is waiting when the event occurs: a count is kept in the 
semaphore of all events that occurred (by SIGNAL) but were not 
received (by WAIT). (Reference Section 4, 4.2.2 and 4.2.3 for 
further informatio on SIGNAL and WAIT.) 


Rx defines semaphores as structures composed of three elements: 


1) A non-negative counter of unserviced events 


2) A queue (possibly empty) of suspended processes. In 
this queue, processes are made ready on a first-in 
first-out (FIFO) basis 


3) A level specifying the interrupt levels that this 
semaphore may be associated with. : 


A semaphore is operated on by several procedures, the most 
important of which are WAIT and SIGNAL. These operations are 
implemented as routines, but are executed as though they were 
Single machine instructions. Until these operations have 
completed, nothing can access the semaphore, the queues, or the 
operations themselves. This is assured when the interrupt mask is 
set to zero upon entry to the routines, and reset to its previous 
state upon exit. 


WAIT decrements the counter; if the counter is zero, -the 
currently active process is suspended (the process is moved from 
the active queue to the semaphore queue). 


SIGNAL increments the counter if the semaphore queve is not 


empty, the first process in the queue (which will always be the 
process that has been in the queue the longest) is activated by 
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moving the first process from the semaphore queue to the ready 
queue. | 


When semaphores are used to ensure exclusive access to two or 
more resources, extreme caution must be exercised to prevent a 
condition Known as "deadlock". This takes place when a_ situation 
is created in which two or more processes are suspended, awaiting 
a condition that cannot happen because there is no active process 
to cause the needed event to occur. 


For example, if two simultaneously executing processes (A and B) 
both require exclusive access to resources (X and Y), the 
following sequence can result: 


Incorrect (deadlock) Correct 
A gets X, A requests Y A requests X, then Y 
B gets Y, B requests X B requests X, then Y 


In the above incorrect example, neither A nor B will ever resume 
execution, as A will be waiting for Y (which B has) and B will be 
waiting for X (which A has). The safest way to prevent such a 
situation is for all processes to request resources in the same 
Order. In the above correct example, the X resource is used as a 
"lock"; if a process can allocate X it is guaranteed to find the 
rest of the resources available. 


2.3.3 Interrupts 


Interrupts are hardware-signalled events, usually associated with 
system peripheral or process monitoring devices. With RX , 
Processes may be specified to service interrupts. These processes 
must have a priority greater than or equal to the interrupt level 
which they will service. Level 0 denotes the highest priority: 
the RESET interrupt; all other interrupt level or device process 
Priorities must be between 1 and 15. 


There are several Rx routines that are used to associate 
semaphores with hardware interrupts. The primary two being 
Procedure EXTERNalevent and Procedure ALTEXTernalevent. (Section 
4, 4.3 lists and describes these procedures.) | 


The CPU has a priority ranking system to resolve conflicts 
between simultaneous interrupts, and a level mask to disable 


lower priority interrupts. A process waits on an interrupt -by: 


waiting on a semaphore associated with the interrupt. (The 
process will have a priority level number less than or equal to 
the interrupt to be serviced.) The process is suspended until an 
interrupt at the appropriate level occurs. When the interrupt 
occurs, the process is scheduled to service the interrupt as the 
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CPU performs a context switch to the interrupt service routine. 
The interrupt mask of the process prohibits further interrupts 


from this or any lower priority device while the interrupt is 
being serviced. 


There are three methods by which the user can write an interrupt 
handler. The first uses the Rx procedure EXTERNalevent to assign 
a semaphore to an interrupt. The second uses’ Procedure 
ASSEMBlyevent (See Section 4) to assign a dedicated assembly 
language interrupt handler. The last method entails writing a 
routine external to the Rx environment. 
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The Rx method shown in Figure 2-3 is useful to the user because 
it is flexible: the interrupt is reset and can be associated with 
another semaphore to perform its function over and over again. 


In the interest of speed, however, the second method illustrated 
in 2-3 using a dedicated interrupt handler can be chosen. This 
involves the user writing a piece of code completely outside the 
RX environment that will process the interrupt. 


In the 9900 Family CPU, when the interrupt occurs, a_ context 
Switch is performed. The contents of the current workspace (WP) 
and program counter (PC) registers are saved and then loaded with 
the address of the new WP and PC which are fetched from _ the 
appropriate interrupt vector, and stored. (This identifies the 
location of the workspace assigned to the interrupt’ service 
routine.) When- the context switch is completed, processing 
resumes with the first instruction of the interrupt’ service 
routine (the user”’s interrupt handler code). Processing will 
continue in this mode until an RTWP instruction is’ encountered, 
and a reverse context switch returns control to the previous 
program in Rx. : 


Although the dedicated interrupt method is faster than the Rx 
method, there is a drawback: the workspace areas created for the 
context must reside in memory space (RAM) not Known to Rx, and 
therefore cannot be reclaimed for use by Rx. In addition, 
interrupts must be masked during execution of the interrupt 
handler. LIMI O as the first instruction in the interupt handler 
results in the required masking of interrupts. 


2.4 MEMORY ORGANIZATION 


The following concepts deal with the utilization of memory in the 
RX environment. Memory is allocated and used to hold variables 
and workspaces for each process, procedure and function through 
the use of the "stack" and "heap" concepts which are described in 
the following subsections. It may be said that Rx "owns" the 
memory allocated to it and "loans" it to processes as they need 
it, for as long as they need it. 


2.4.1 Heap 


The system heap is all available RAM memory allocated to the 
system when it is started. It is from this heap that all future 
memory allocations to starting processes will come. Each process 
that calls another process, procedure or function will be the 
"parent" that allocates memory for use by the routines it 
"spawns" or calls. A process, then, is allocated heap and stack 
from its lexical parent”“s heap. (Note that heap should be 
allocated to a process if that process will be starting any other 
to ensure there will be enough memory for the called process” 
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stack.) 


A process” heap is an area of memory allocated in packets’ which 
may be disposed of and used again. These packets are used as 
storage for dynamically allocated variables. When required, a 
call to NEWS by the executing process requests a packet of memory 
of a certain size and sets a pointer to this packet. When the 
process no longer needs this space, a call to FREE$ returns’ the 
packet to the "pool" where it can be used again. 


2.4.2 Stack 


This is a region of memory associated with a process. A separate 
stack region is allocated to each instance of a process when that 
process is started (via SS$PRCS). Although the "top" and "bottom" 
of a stack are fixed, the use of the area inside is dynamic. 
Space is allocated to procedures and functions by Rx from _ both 
ends, working toward the middle, since both local variables and 
workspace areas are required. 


Every invocation of a procedure or function requires a workspace 
for the called routine. Space in which to store local variables 
(i.e., variables that will be used by the called routine), as 
well as other data is also needed. This space is called the stack 
frame. Memory is allocated from the top down for workspaces, and 
from the bottom up for stack frames; a stack overflow would 
indicate that the two have met in the middle. (Reference Appendix 
A for further information on stacks and stack frames.) 


In Figure 2-4, the concepts of stack and heap are depicted, 
beginning with the initial allocation of system heap and 
progressing through the starting of the lexical level 1 process 
which, in turn, calls a_e subordinate process. (Note the 
allocations of stack and heap by the lexical parents.) 


Note that processes must have a stack region but are not required 


to have a heap region unless they start another process or use 
dynamically allocated heap packets. 
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FIGURE 2-4. STACK AND-HEAP ALLOCATIONS IN Rx. 


2.5 SYSTEM INITIALIZATION 


Initialization is accomplished by a hardware interrupt 
oth ger: for the processor hardware aeerte peveiratube 
vector contained in low memory points’ to the Sica eee arc 
RXINIT declares the default system crash routine (whi whet 
Of an IDLE instruction), and starts the BOOTS Schl ee or 
initializes system data structures, starts the IDLE Zoe one 
then calls the GHOST procedure. GHOSTS, in — _ oe 
user”s system module at the SYSTMS designation. .(No et ee 
may be customized to perform fe emer pe di p 
initialization (refer to 6.3 for further information). 
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FIGURE 2-5. Rx SYSTEM INITIALIZATION. 


2.6 SUMMARY 


The software tools discussed in this section provide interprocess 
scheduling and coordination of system resources in Rx. While 
Simple in terms of construct, these tools provide a 
sophistication in capability that enables a higher programmer 
productivity using a realtime programming environment. Detailed 
information on how to write Rx applications using the concepts 
described follows in Section III. 
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SECTION 3 


Rx CONVENTIONS 


‘3.1 GENERAL 


When writing software to be used with Rx, certain conventions must be 
followed when interaction is required between the application software 
and the executive environment. These conventions apply to the way in 
which the application code is structured, how routines are called, and 
which registers may be used. The following sections detail these 
conventions as they apply to Rx procedures, functions, processes, and 
systems. 


When using the Rx routine linkage mechanisms described in 3.2, the 
routines must be structured according to the proper module format 
(i-e., Procedure, function, process). These linkage and module format 
conventions give the code certain properties which increase the 
reliability and flexibility of the software. Linkage conventions 
produce code which is reentrant. Reentrant procedures may be executing 
within more than one process at a time without erroneous results. By 
using the same portion of code to do two or more concurrent’ tasks, 
memory space is conserved. The standard linkage conventions also 
produce code which is recursive, allowing the procedure to call 
itself. This property can be very useful when solving certain types of 
complex problems. 


3.2 LINKAGE CONVENTIONS 


There are two types of linkage supported within Rx: standard and 
optimized procedure/function linkage. The standard linkage provides a 
modular approach to writing these routines. It allows the calling 
procedure to know nothing about the called procedure except the 
arguments passed between them (no registers must be saved, etc.). The 
optimized linkage provides a faster linkage mechanism for routines 
which will not call any other routines or need any local storage. 


3.2.1 Standard Procedure/Function Linkage 


The standard procedure/function linkage supports parameter passing, 
local storage, reentrancy, and recursion. It achieves these by using 
the stack data structure illustrated in Figure 3-l. In this stack, 
stack frames grow from the bottom toward high memory while workspaces 
grow from the top toward low memory. The stack region is allocated 
when the process is created. A stack overflow error occurs when there 
is not enough stack for another procedure call (the stack frames and 
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points to the base of the process stack, while the local frame pointer 
(R9) points to the global stack frame which is a separate memory 
packet. 'In the example, a routine has been called from another routine 
nested within a process. The calling routines stack pointer (R10) and 
local frame pointer (R9) are shown on the left. These pointers, other 
system pointers, and the routine’s general registers are contained in 
the calling routine”s workspace. The called routine has a new 
workspace allocated to it which is pointed to by the workpsace pointer 
shown on the right. Registers RY and R10 in this workspace point to 
its local frame and current top-of-stack. Both the parameters and 
local storage are referenced using R9 (LF) as the base register. This 
type of routine nesting repeats for as many routines as are called. As 
routines return to their caller, their stack frame and workspace are 
returned to the unused portion of the stack. 


The stack frame for a standard procedure/function is determined by the 
routine prologue described in Sections 3.3.1 and 3.3.2. Basically, the 
routine prologue specifies how many parameters the called routine 
expects the calling routine to have pushed and how much local storage 
the called routine needs. Both the parameters and local storage are 
referenced using R9(LF) as the base register. 


A routine with standard linkage has two data areas that it may access 
during execution. It may use any of the general registers (described 
in Section 3.4) and the local storage space of its stack frame. The 
general registers should be used for frequently accessed data or if 
only a few words of storage are needed. If the general registers do 
not provide enough data space, then either local storage or the’ stack 
must be used. Local storage is an area reserved in the stack 
immediately above the passed parameters that remains allocated until 
the routine returns. Therefore, this space should be used for data 
which will be accessed during nested routine calls. When a routine is 
Called, there must be enough unused stack to allow for the standard 
linkage memory requirements. These requirements include the new 
workspace, the passed parameters, and any local storage. When enough 
stack does not exist, a stack overflow error occurs. The process stack 
size is contained in the literals field of the process” code. 


When a process is invoked, its stack is allocated with the desired 
size, and its workspace is defined and initialized. Its process record 
is also created, the first field of which is contains a pointer to the 
first’ 32 bytes of unused workspace stack which resides just before 
this new process’s initialized workspace. This pointer is called the 
"next workspace" pointer and will be used as the workspace pointer of 
any routine called from the process module. Whenever a routine is 
Called, the linkage handler decrements "next workspace" by 32 bytes to 
be prepared for the next call. As a result of this algorithm, the 
unused stack region will always be at least 32 bytes long, and it will 
always be possible to use this amount of stack without overflow 
occurring. For example, 16 ne-word parameters could be pushed onto 
the stack without danger of over-writing the current workspace. If the 
Parameters intrude into what will become the called routine’s 
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workspace, they may be modified as linkage handler executes out of the o 


-new workspace; however stack overflow will be detected before the 
called routine can make use of the erroneous parameters. CAUTION: if 
more parameters are pushed and there is no additional unused stack 
other than the next workspace, the contents of the allocated 
workspaces of previously called routines may be destroyed, and 
catastrophic errors may occur which are impossible to recover from and 
difficult to debug. If a routine will pass more than 32 bytes of 
Parameters, the following code should inserted into the prologue of 
that routine to make a pre-emptive stack overflow check: 


BL  @STKSCK 
DATA "maximum number of bytes to be Pushed" 


The "next workspace" field of the process record in incremented by 32 
at exit from a routine to reclaim the space used for its workspace. 


To make use of the standard linkage, a routine must be called in the 
Proper manner. Parameters can be passed in two different ways: by 
value and by reference. A value parameter contains the actual value 
being passed, while a reference parameter is the address of the 
variable. The user should be sure that a parameter is referenced in a 
consistent manner. An example of a call using the standard routine 
linkage is as follows: | 


Code in the calling routine: 


MOV @PARM1,*R10+ PUSH FIRST ARGUMENT 
MOV @PARM2,*R10+ PUSH SECOND ARGUMENT 
MOV @PARMn, *R10+ PUSH (n)th ARGUMENT 
DATA CALLS, ROUTIN CALL ROUTINE *ROUTIN~ 


Code in the called routine: 


MOV *R9,@ARG1 SAVE ARGUMENT ONE 
MOV @2(R9) ,@ARG2 SAVE ARGUMENT TWO 


MOV @2*n-2(R9),@PARMn SAVE ARGUMENT n 


If any local storage is specified, this storage begins at an address 


pounced to by the displacement (2*n) off of RI and extends for as many 
ytes as specified. 


Function linkages are similar, and arguments are passed in exactly the 


_ same way. The function result is returned at the end of the_ stack; 
1-@-. upon return from the function, the stack pointer R1O points to 
the first word of the result, which may be 1 byte, 2 bytes, or 4 bytes 
long. 
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For detailed examples of subroutine linkage see the routine templates 
in Appendix C, and the demonstration program in Appendix E. 


The actual linkage functions are performed by the standard RX routine 
CALL$$. This external symbol CALLS is resolved to be the instruction 
BLWP *PR which performs a "branch and link workspaces" using the 
transfer vector contained in the first two words of the process record 
of the active process. As mentioned previously, the first word in the 
Process record is a pointer to the next workspace. The second word 
contains the address of the entry handler, CALL$$. The resulting 
action is a branch to CALLS$ and begin executing in the "next 
workspace." CALLS$ initializes registers in the new workspace, resets 
the next workspace pointer in the process record, and branches to the 
code of the called routine. 


When the calling routine has completed, it returns via a branch or 
branch and link to the exit routine. This routine deallocates the 
stack frame and workspace allocated to the execution of the calling 
routine. ; 


3.2.2 Optimized Linkage 


An alternative to the standard routine linkage is the optimized 
linkage mechanism. This linkage executes faster than the standard 
linkage since it does not perform as many functions: a new workspace 
is allocated and initialized for the called routine; local storage, 
other than the space needed for passed parameters, is not allocated. 
Any routine which was called with the optimized linkage cannot call 
other routines. 


Figure 3-2 illustrates a process stack after an optimized linkage. The 
calling routine”s workspace pointer and registers are shown on the 
left, while those of the called routine are shown on the right. 
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The stack frame, eneral registers, and unused stack are available to 
an optimized routine. Since the optimized linkage produces a stack 
frame which is only used for passed parameters, local storage is not 
reserved. | 


The calling sequence to an optimized routine is identical to the 
calling sequence for a standard linkage routine. This similarity 
allows the calling routine to call other routines without knowing 
whether they are coded for either standard or optimized linkage. When 
the MPX linkage routine determines that the called routine is using 
the optimized linkage, it initializes workspace registers and branches 
directly to the new routine’s code. Since a routine with optimized 
linkage is not permitted to call other routines, there is no need to 
update the "next workspace" pointer in the process record. The called 
routine with optimized linkage references the passed parameters in the 
same way as the standard linkage routine. 


When the optimized routine has completed, it returns to the calling 
routine via a return with workspace pointer (RTWP) instruction. This 
takes the saved workspace pointer, program counter, and status from 
registers R13 through R15 and restores them. 


3.2.3 Process Linkage 


The process linkage mechanism is very similar in use to the standard 
procedure/function linkage. The process is called in an identical 
manner; however parameters can only be passed by value. ‘The called 
process gets the parameters in an identical manner. However, the 
effect on the stack is quite different. The initial code of a process 
contains calls to the executive which create a new stack region (along 
with a process record and other process data structures) for the new 
Process to execute from. Once this initial code has executed the 
Calling procedures stack returns to the state it was in prior to 
pushing parameters and calling the process. The new processes” stack 
and process’ record are allocated from the heap region of its calling 
process. If the calling process does not have a heap, the stack and 
heap are allocated from the system heap. 


NOTE: for one process to start another, about 144 bytes of stack space 
are required. 


3.3 SOURCE MODULE FORMAT 
To make use of the Rx linkage mechanisms, routines must be formatted 
in a certain structure. It is this structure which allows the linkage 


mechanism to operate. The basic structure consists of the following 
segments within the routine: | 


Cg LE Ne oy TR rte ie See 





routine 
descriptor 


routine 
prologue 


routine 
body 


routine 
epilogue 


The routine descriptor contains constants needed by the linkage 
routine upon routine entry. The routine prologue contains any code 
necessary to start the routine. The routine body is the code which 
actually performs the purpose of the routine. The routine epilogue is — 
the code required to exit the routine. Some routine types do not 
require all of these code segments. The different routine formats are 
Summarized in Appendix C. 


3.3.1 Standard Procedure 


A standard procedure requires a desriptor with the following 
information: 


#00 -—----------- <--- Procedure address 
prologue Displacement to start of code 
(bytes). 
$02 [~~~ -..-~~.-- 
epilogue Displacement to epilogue of routine 
(bytes) 
#04 8 | -~---------- 
local Size of local variable portion of local 


frame (bytes) 


frame size Routine frame size (bytes) 


The start offset defines the offset to be added to the procedure 
address for the initial procedure program counter. The end offset 
defines the offset to be added to the procedure address in case the. 
procedure is aborted. The local size specifies how many bytes’ should 
be allocated from the stack when the procedure is called for use as 
local storage. The frame size specifies the total stack frame size 
including passed parameters and local storage. Both the local size and 
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frame size should be even values. 


The prologue of a procedure is usually just a label which is 
immediately followed by the procedure”s main body. 


The procedure body consists of the assembly language statements 
required to achieve the procedure’s desired effect. (This will vary 
from procedure to procedure). 


The procedure epilogue contains a branch to the Rx procedure exit 
routine EXITSP. This routine returns execution to the calling routine. 


3.3.2 Standard Function 


The standard function format is very similar to the standard procedure 
format, the only difference being that the epilogue section of the 
function must return the function result. A standard function epilogue 
consists of the following: 


BL @EXITSn 
DATA mmmm 


In this example, "n" is the length of the result in words and “"mmmm" 
is the displacement into the stack frame in bytes of the result. The 
EXIT$n routine returns the function result at the stack pointer of the 
calling routine and returns execution to the calling routine. 


3.3.3 Process 


The standard process format contains a descriptor with the following 
information: | 


#00 ------------ <--- process address 
start Offset to beginning of 
offset process prologue (in bytes) 
#02 | ene eee = 
end | Offset to process 
offset epilogue (in bytes) 
#04 |----~------- ; 
0 zero constant 
#06 | ----------—-- 
Parameter Size of passed parameters 
size (in bytes) 





The start offset and end offset have the same meaning as for a 


procedure or function. The parameter size specifies how many bytes of. 


Parameters that the starting routine has pushed onto the stack. The 
zero constant specifies how much local storage should be allocated. 
This is always zero because a process is invoked in two steps. The 
first phase invokes the process routine as a standard procedure with a 
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stack frame just large enough to contain to process”s parameters; the 
"Q" in the process descriptor suppresses allocation of local 
variables. When the process routine is entered, it calls procedure 
SSPRCS to perform the second phase of process invocation by using 
constants in the literals section to create the data structures’ that 
permit the new process to become a separate site of execution. In 
Particular, one of these literals is the total frame size of the 
process module. (With this implementation the invoking process need 
not have enough stack space to hold the global frame of the new 
process.) | 3 


The literals segment contains the following: 


(1) routin PSEG 


(2) EQU §$ Origin of process 
(3) frmsiz DATA >nnnn Total size of stack frame needed for 
| process body (in bytes) 

(4) lexlvl DATA >nnnn Lexical nesting level. | 

(5) priori — Process Priority. 

(6) stksiz Size of stack region to be allocated for 
Process (in words). , 

(7) hpsize Size of heap required for process (in 
words). 


The frame size specifies the process’s global stack frame size. The 
lexical level specifies the number of levels that this process is 
nested within other processes. The lexical level of a system process 
is 0, a Drogram process started from the system has a lexical level of 
1, a process started from a program has a lexical level of 2, eth. 
These lexical levels are not enforced by the system, but are 
conventions which the user must follow to allow variable scoping and 
communication with other software using the RX Executive. 


The process priority specifies the relative urgency of this process 
compared to other processes. The lower the numerical priority, the 
greater the urgency. The process stack size specifies how many words 
of stack will be required for the routines within the process. The 
process heap size specifies how many words of heap memory the process 
will need. Any user defined constants are stored after the heapsize, 
and before the first executable statement. 


The prologue of a process body is required to initialize the process 


data structures and schedule the process according to its priority. 
The prologue contains the following start up code: 





Prolog EQU | 
MOV @frmsiz-routin(R8),*R10+ Push frame size (in bytes) 
MOV @LEXLVL-routin(R8) ,*R10+ Push lexical level 
MOV @PRIORI-routin(R8) ,*R10O+ Push process priority 
MOV @STKSIZ-routin(R8) ,*R10+ Push stack size (in words) 
MOV @HPSIZE-routin(R8),*R10+ Push heap size (in words) 
DATA CALLS$,S$PRCS Call start process 


This code passes the necessary parameters from the literals segment to 
the process start procedure SS$PRCS. All of the parameters do not 
necessarily have to be distinct entries in the literals section. The 
code can be optimized so that the parameters are shared or omitted 
altogether. For example, if a system process with a zero frame size, 
priority, stack, and heap size were started, the literals section 
could be empty and the prologue optimized. 


CLR *R10+ | PASS FRAME SIZE 
CLR *RI10+ PASS LEX LEVEL 
CLR *RI10+ PASS PRIORITY 

CLR *R10+ PASS STACK SIZE 
CLR *R10+ PASS HEAP SIZE 
DATA CALLS CALL START PROCESS 


DATA SSPRCS 


The SS$PRCS routine concludes the second step of process 
initialization. Not only does it allocate and initialize the new 
process’s data structures, it also copies the parameters contained in 
the temporary stack frame into the new global stack frame and sets the 
contents of the new process workspace to begin execution at the first 
instruction following the call to SSPRCS. The temporary workspace and 
stack frame are then returned to the unused stack of the starting 
process. 


The epilogue of a process terminates execution of the process’ by 
Calling the MPX routine ES$PRCS to deallocate its resources. Its 
Process record and stack region are deallocated immediately; the 
global stack frame is deallocated after all offspring processes have 
terminated. The epilogue contains the following termination code: 


MOV @LEXLVL-routin(R8),*R10+ PUSH LEX LEVEL 
DATA CALLS$,ESPRCS CALL PROCESS TERMINATION ROUTINE 
B @EXITSP COMPLETE TERMINATION PROCESSING 


This code passes the lexical level to the process termination routine 
and then branches to the procedure exit routine. | 








3.3.4 Optimized Procedure 


The optimized routine format is fairly simple. The format of an © 


optimized routine is as follows: - 


#000 0 ----------=- <--- Descriptor 
negative 
parameter 
size 
#02 | ------------ <--- Body 
routine 
body 


Seboseacaose <--- Epilogue 


The descriptor contains only the negative value of the parameter size 
(or zero if the routine has no parameters). This non-positive value 
indicates to the linkage routine CALLSS that this routine is in an 
optimized format. The actual parameter size can then be easily 
computed by negating the value. The routine body contains no prologue. 
The epilogue is only a return with workspace pointer (RTWP) 
instruction which causes execution to return to the calling routine 
when this routine is finished. 


3.3.5 Optimized Function 


An optimized function format is very similar to an optimized procedure 
format. The difference is the epilogue which must contain the 
following: 


REF EXITSO OH, NOT ZERO 
MOV @RESULT,*LF |= SAVE RESULT ON THE STACK 
BL @EXITSO CALL EXIT ROUTINE 


The function result is stored in the location pointed to by R9 (LF), 
and the EXITSO optimized exit routine is called. This routine’ saves 
the status so that it is available to the caller. The calling routine 
retrieves the result from the location pointed to by its own stack 
Pointer (R10). Note that EXITSO only allows one word function results. 


3.4 REGISTER USAGE 


RX useS certain registers within procedure, function, and process 
workspaces to maintain system level pointers. These registers must not 
be changed by the application software or erroneous results may occur. 
The following registers may NOT be changed when using optimized 
linkages: 





R13 - Old Workspace Pointer. This register maintains 
a link to the previous routine’s workspace. 


R14 - Old Program Counter. This register maintains a 
link to the previous routine”’s program counter. 


When using the standard linkage mechanism, the following 
registers are assigned special purposes and may not be altered by 
the application software: | 


R7 - Process Record Pointer. This register contains 
the address of the process record for this process. 


R8 - Code Base. This register contains the address 
of this routine and may be used as a base register. 


R9 - Local Frame. This register contains the address 
of this routine”s stack frame which contains passed 
parameters and local storage. 


R10 - Stack Pointer. This register contains this 
routine’s stack pointer. 


R15 - Status Register. This register stores’ the 
summary of the results of the processor operation. 


The user may, for convenience, include the following equates in 
his programs: 


PR EQU 7 
CODE "EQU 8 
LF EQU 9 
SP EQU- 10 


The remaining registers RO, Rl, R2, R3, R4, R5, R6, Rll, and R12 
may be used by the application software. Rll is used by the BL 
instruction to hold the return, address, and may be used as_ such 
for subroutine linkage outside of the Rx environment. Rl2 is 
reserved as the CRU base if any CRU operations are to _ be 
performed. 


3.5 EXAMPLE PROGRAM 


A portion of the Rx demonstration program is included at the end 
of this section as an example of an RX program. A complete system 
is included in Appendix E. 


This routine takes three arguments: (1) the CRU address of a 
terminal, (2) a baud rate flag (which is returned by a routine 
which sets the baud rate of the terminal), and (3) a pointer to a 
message which is terminated by a null character (>00). 








This program loops through the string and calls another’ routine 
TISCOT to print the character on the terminal. TISCOT also takes 
three arguments: (1) the CRU address of a terminal, (2) a baud 
rate flag (which is returned by a routine which sets the baud 
rate of the terminal), and (3) the character to be printed. 
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WAITIO 
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0380 
0381 
0382 
0383 
0384 
0385 
0386 
0387 
0388 
0389 
0390 
0391 
0392 
0393 
0394 
0395 
1396 
0397 
0398 
0399 
0400 
0401 
0402 


0403. 


0404 


~ 0405 


,. 0406 
0407 
0408 
0409 
0410 
0411 
0412 
0413 
0414 
0415 
0416 
0417 
0418 
0419 
0420 
0421 
0422 
0423 
0424 


SDSMAC 3.3.0 79.312 


0000 
0002 
0004 


0001 
0002 
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* 
TISMSG: 


+ + + + 


PURPOSE: 


INPUTS : 


OUTPUTS: 


CALLS : 


+ +t + Ft HF FF EF eH FF FH HF HF FH FE FH OF HE FH HE HE HF 


REFERENCES 


REF 
REF 
* 


* EQUATES 
* 

PORTOF EQU 
BAUDOF EQU 
MSGP EQU 
* 


MSGPTR EQU 
WORD  EOQU 


OUTPUT A STRING, DELIMITED BY A NULL 


OUTPUT A STRING TO A 9902 PORT. THE STRING 
IS COMPOSED OF CONSECUTIVE BYTES POINTED 
TO BY THE THIRD ARGUMENT, AND DELIMITED BY 
A ZERO BYTE. 


CALLING SEQUENCE: 


PUSH CRU ADDRESS OF PORT 
PUSH BAUD RATE FLAG FROM TISSET 
PUSH POINTER TO MESSAGE STRING 


MOV @<CRU ADDRESS>, *SP+ 
MOV @<BAUD RATE FLAG>,*SP+ 
MOV @<PTR TO MSG>, *SP+ 
DATA CALLS, TISMSG 


PORT: CRU BASE OF OUTPUT PORT 
BAUD: BAUD RATE FLAG FROM TISSET 
MSGP: POINTER TO MESSAGE STRING 


OUTPUT IS SENT TO PORT. 


EXCEPTIONS: NONE. 


TISCOT 
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CALLS , EXITSP 
TISCOT 


ADDRESS 2 
INTEGER 2 
POINTER 2 


>0000 
>0002 
>0004 


* 


* 
* 
* 
* 
* 
* 
* 
* 
* 
x 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
x 
* 
* 
* 
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0426 
0427 
0428 
0429 
0430 
0431 


0126 


0126 
0128 
012A 
012c 


WAITIO 
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0433 
0434 
0435 


0436 
0437 


0438 
0439 
0440 


0441 
0442 


0443 
0444 
0445 


0446 
0447 
0448 
0449 
0450 
0451 


0452 


012k 
0130 
0132 
0134 
0136 
0138 
O13A 
013Cc 
0135 
0140 
0142 
0144 
0146 
0148 


014A 
014C 


NO ERRORS, 
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PSEG 
Q126° TISMSG EQU $ 
0008 DATA 
0024 DATA 
0000 DATA 
0006 DATA 


SDSMAC 3.3.0 79.312 


c069 
0004 
04¢C2 
pOB1 
1309 
CEA9 
0000 
CEA9 
0002 
06C2 
CE82 
0000 
O0OA0 
10F4 


0460 
0000 


* 


CHARLP 


a 


MOV 


CLR 
MOVB 
JEQ 
MOV | 


MOV 
SWPB 
MOV 
DATA 


JMP 


09:59:39 THURSDAY, MAY 07, 1981. 
TISLIB -- WAIT LOOP DRIVEN I/O -- 6/25/80 


MSGENT-TISMSG 
MSGEXI-TISMSG 
0 

6+0 


09:59:39 THURSDAY, MAY 07, 


$ 


@MSGP (LF) ,MSGPTR 


WORD 
*MSGPTR+,WORD 
MSGEXI 
@PORTOF (LF) , *SP+ 


@BAUDOF (LF) ,*SP+ 


WORD 


WORD, *SP+ 
CALLS , TISCOT 


CHARLP 
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OFFSET TO EXECUTABLE CODE | 
OFFSET TO TERMINATION CODE 
LOCAL VARIABLE SIZE 

LOCAL FRAME SIZE 


1981. 
PAGE 0014 


MSGENT POINT OF PROCESS 


GET POINTER TO MESSAGE 


ZERO BOTH BYTES 

CHR IN HIGH BYTE OF WORD 
YES: QUIT 

PUSH PORTOF 


PUSH BAUDOF RATE FLAG 
CHR IN LOW BYTE OF WORD 


PUSH WORD ON STACK 
SEND CHR 


Lee eee REESE EEE EEE EEE RE PRR ERERE REESE REE RSE SESE SEE EERE RSE SEE ES 


---- END OF CODE ---- ek 
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014A” MSGEXI EQU 


* 


B 


END 


NO WARNINGS 


$ 
@EXITSP 


EXIT CODE 








SECTION 4 


Rx ROUTINES 


4.1 GENERAL 


This section describes user-callable routines within the Rx executive 
package. These routines are intended to perform commonly needed 
functions within a software system. Use of these routines will 
considerably reduce application software complexity while increasing 
its reliability and understandability. 


The routines are grouped according to function, and the purpose of 
each routine described in detail. The required parameters and calling 
sequence are listed along with any possible side effects or errors. 


4.2 LINKAGE ROUTINES 


The linkage routines are used to call and return from procedures, 
functions, and processes. 


4.2.1 Procedure CALLSS 


This nonstandard procedure performs the necessary linkage for standard 
procedures, standard functions, standard processes, optimized 
procedures, and optimized function calls. A BLWP vector contained at 
the beginning of each process record points to this routine and the 
next available workspace. The routine is entered by performing a BLWP 
*R7 (R7 points to the current process record). This BLWP instruction . 
has been equated to the symbol CALLS. 


The first word of the routine descriptor is compared to zero. If it is 
zero, an optimized linkage is assumed and the routine is immediately 
entered. If the first word of the desriptor is nonzero, a standard 
linkage is performed. The standard linkage includes allocating a 
workspace for nested routines, initializing the stack pointer (R10), 
a local storage, and initializing the local frame pointer 
(R9). 


EXAMPLE : 


REF routine 


DATA CALLS 
DATA routine 
EXCEPTIONS AND CONDITIONS: A stack overflow error occurs during a 
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standard linkage if there is not enough stack remaining to allocate 
the new workspace. 


° 4.2.2 Procedure EXITSP 


This nonstandard procedure performs the return from a_e standard 
procedure. The next workspace (for nested routines) is deallocated and 
a RTWP is performed to return to the caller”s context. 


EXAMPLE : 


REF EXITSP 


B @EXITSP 


EXCEPTIONS AND CONDITIONS: None. 


4.3.3 Procedure EXITSn 

This nonstandard procedure returns “n~ words from a standard function. 
The next workspace (for nested routines) is deallocated. Then “n° 
words at “OFFSET” bytes into the function local frame (R9) are 
returned at the caller’s stack pointer (R10), “n* must be either l, 2, 
or 4. Upon return from this routine, the caller’s stack pointer (R10) 
points to the first word of the function result. | 


EXAMPLE : 


REF EXITSn 


BL EXITSn 
DATA nnnn “OFFSET” INTO LOCAL FRAME 


EXCEPTIONS AND CONDITIONS: The caller’s condition code is set based on 


the returned result. 


4.2.4 Procedure EXITSO 


This nonstandard procedure returns 1 word from an optimized function. 
The next workspace (for nested routines) is deallocated. Then 1 words 
at “OFFSET* bytes into the function local frame (R9) are returned at 
the caller’s stack pointer (R10); upon return from this routine, the 
Caller”s stack pointer (R10) points to the function result. 











EXAMPLE: 


REF EXITSO 


BL EXITSO 
MOV result,*LF 


EXCEPTIONS AND CONDITIONS: The caller”s condition code is set based on 
the returned result. 


4.2.5 Procedure SSPRCS 


This procedure is called by the prologue of a process to initialize 
its data structures and start itself. It allocates a process’ record, 
process stack, and routine stack from its parent’s heap and then 
initializes all the necessary fields in these structures. The new 
process is then inserted into the ready queue according to its 
priority. | 


EXAMPLE : 


REF SSPRCS 


MOV @<ga>,*R10+ PUSH FRAME SIZE IN BYTES 
MOV @<ga>,*R10+ PUSH LEXICAL LEVEL 

MOV @<ga>,*R10+ PUSH PROCESS PRIORITY 
MOV @<ga>,*R10+ PUSH STACK SIZE IN WORDS 
MOV @<ga>,*R10+ PUSH HEAP SIZE IN WORDS 
DATA CALLS 


DATA SSPRCS 
EXCEPTIONS AND CONDITIONS: Errors will occur if there is not enough 
Parent heap to allocate data structures, if the called process does 
not have enough stack, or if the lexical level is invalid. 
4.2.6 Procedure ESPRCS 
This procedure is called by the epilogue of a process to terminate it. 
EXAMPLE: | 


REF ESPRCS 


MOV @<ga>,*R10+ : PUSH LEXICAL LEVEL 
DATA CALLS 
DATA ESPRCS 


EXCEPTIONS AND CONDITIONS: None. 








4.3 SEMAPHORE ROUTINES 


These procedures synchronize processes on the basis of events. 


4.3.1 Procedure INITSEmaphore 


This procedure initializes the semaphore SEMA. It allocates’ three 
words from the system heap for the semaphore record and puts the 
address of this record at the specified location. Recall that a 
semaphore is defined as the address of the semaphore record. It uses 
the parameter COUNT as the initial value of the number of unprocessed 
(unreceived) SIGNALS to the semaphore. It initializes the semaphore 
queue to be empty by setting the queue pointer to Zero. It initializes 
the semaphore level field to be 32767, the lowest urgency level, so 
that while at this level, any process may wait on this semaphore. 


EXAMPLE: 


REF INITSE 


MOV @<ga>,*R10+ PUSH ADDRESS WHERE SEMAPHORE “SEMA*~ 
WILL BE PLACED 

MOV @<ga>,*R10+ PUSH INITIALIZATION “COUNT” 

DATA CALLS : 


DATA INITSE 


EXCEPTIONS AND CONDITIONS: ‘This procedure may fail if there is not 
enough system heap available. It is illegal to initialize the 
semaphore with a negative number. 


4.3.2 Procedure SIGNAL , 


This procedure performs a SIGNAL operation on the semaphore named 
SEMA. The semaphore count field of the semaphore record is incremented 
by one, indicating that another event which requires processing has 
occurred. If the semaphore count field is still less than or equal to 
zero after the increment, there are process(es) WAITing on the 
semaphore, and a scheduling procedure is called. The rescheduled 
WAITing process either preempts the calling process or is placed in 
the ready queue, according to its priority. If the semaphore count 
field is greater than zero after being incremented, the procedure 
Simply returns to its caller, leaving the semaphore with its one extra 


unprocessed (or unreceived) event. If the semaphore count overflows, 
the run-time support exception routine is called. 
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EXAMPLE: 


REF SIGNAL 


MOV @<ga>,*R1l0O+ PUSH SEMAPHORE 
DATA CALLS 
DATA SIGNAL 


EXCEPTIONS AND CONDITIONS: An exception occurs if the semaphore counter 
overflows or if an illegal semaphore counter is passed. 


4.3.3 Procedure WAIT 


This procedure causes a WAIT operation to be performed on the 
semaphore SEMA. The procedure decrements the semaphore count field of 
the semaphore record. If there are unprocessed (unreceived) SIGNALS to 
the semaphore, the procedure simply returns to the calling process. 
If, however, there are no unprocessed SIGNALS, the process becomes 
suspended on the semaphore SEMA and is placed in the semaphore queue 
behind any other WAITing processes. The procedure also checks that the 
priority (contained in the priority field of the process record) is 
numerically less than the semaphore priority level (contained in the 
semaphore level field of the semaphore record). This ensures that if 
the semaphore is ever associated with an interrupt level, any 
processes which are suspended on it are of sufficient urgency to 
handle the interrupt immediately. (If the semaphore was initialized by 
INITSE, its priority field contains 32767 so that any process may wait 
on it.) 


EXAMPLE: 


REF WAIT 


MOV @<ga>,*R10+ - PUSH SEMAPHORE 
DATA CALLS 
DATA WAIT 


EXCEPTIONS AND CONDITIONS: An exception occurs if a process attempts 
to become suspended on ae semaphore when the process priority is 
numerically greater than the semaphore level (i.e., it is not urgent 
enough to WAIT on that semaphore). An exception will also occur if an 
illegal semaphore is passed. 


4.3.4 Procedure TERMSEmaphore 


This procedure is used to terminate a semaphore when it is no _ longer 
to be used. IF there are no WAITing processes (i.e., the semaphore 
count field is not a. negative integer) the procedure passes’ the 
address of the semaphore to the routine HPSFRE which reclaims the 
memory allocated to the semaphore into the system heap. 
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EXAMPLE: 


REF TERMSE 


MOV @<ga>,*R1O+ PUSH ADDRESS OF SEMAPHORE “SEMA” 
DATA CALLS : 
DATA TERMSE 


EXCEPTIONS AND CONDITIONS: An exception will occur if there are 
WAITing processes on the semaphore that is being terminated or if the 
semaphore is illegal. 


4.3.5 Procedure CSIGNA1 


This procedure performs a conditional SIGNAL operation on the 
semaphore SEMA.. It first checks the validity of the semaphore, then 
sets the value of WAITER to false, then masks all interrupts’ and 
checks to see if any processes are WAITing on the semaphore SEMA. It 
does this by looking at the semaphore count field . If the semaphore 
count is less than Zero (there are WAITing processes), the parameter 
WAITER is set true and the procedure branches to the SIGNAL procedure. 
If there are no WAITing processes, the procedure returns with WAITER 
set to false. 


EXAMPLE : 


REF CSIGNA 


MOV @<ga>,*R1O+ PUSH SEMAPHORE “SEMA” 
MOV @<ga>,*R10+ PUSH ADDRESS OF “WAITER” 
DATA CALLS 


DATA CSIGNA 


EXCEPTIONS AND CONDITIONS: An exception occurs when the semaphore 
is illegal. 


4.3.6 Procedure CWAIT 


This procedure performs a conditional WAIT operation on the semaphore 
SEMA. The procedure first checks the validity of the semaphore, then 
masks interrupts, and then tests the semaphore counter. If the 
semaphore counter is less than or equal to Zero (i.e., there are no 
unprocessed or unreceived SIGNALS), control simply returns to the 
caller. If unprocessed SIGNALS exist, the semaphore counter is 
decremented by one, just as if a WAIT operation had been performed 
under similar circumstances. The parameter WAITER is set true if there 
was at least one unprocessed SIGNAL on the semaphore, and false if 
there were no unprocessed SIGNALS. 
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EXAMPLE: 


REF CWAIT 

MOV @<ga>,*R10+ PUSH SEMAPHORE “SEMA” 
MOV @<ga>,*R10+ PUSH ADDRESS OF “WAITER” 
DATA CALLS 

DATA CWAIT 


EXCEPTIONS AND CONDITIONS: Because this procedure never results in 
suspension of the calling process on the semaphore, the procedure does 
not check the process priority; however, an invalid semaphore will be 
detected. 


4.3.7 Procedure WAITSIgnal 


This procedure performs a WAIT operation on the semaphore WAITFOR and 
a SIGNAL operation on the semaphore SIGNALTHE, in a single indivisible 
step. This procedure ensures that both operations are performed at 
once, which cannot be done by performing a SIGNAL followed by a WAIT 
Or vice versa. In the first case, the SIGNAL might cause another 
process to preempt the current process before it does the WAIT; in the 
second, the process might become suspended when it does the WAIT 
before it can do the SIGNAL. 


WAITSIgnal first checks the validity of the semaphore, then masks all 
interrupts. Next, WAITSIgnal decrements the semaphore counter of the 
WAITFOR semaphore. This is the essential part of the WAIT operation. 
If this action leaves the semaphore count greater than or equal to 
zero, (i.e., will not cause the process to become suspended), a signal 
operation is performed on the SIGNALTHE semaphore (without using 
another workspace). Control returns to the calling process if no 
process is waiting on the semaphore. 


If a decrement to the semaphore count will cause suspension of the 
Calling process, the routine S$WAIT is executed. SWAIT performs a 
variety of functions. It verifies that the process has’ sufficient 
urgency to wait on the semaphore (i.e., that the process priority is 
numerically less than the semaphore level). It sets the semaphore 
pointer field in the process record to point to the semaphore on which 
the process is suspended. It places the process on the semaphore 
queue, stores the workspace pointer and becomes ready to perform the 
context switch. 


Having completed the WAIT operation, but before the context switch is 
performed, WAITSIGNAL performs an operation similar to SIGNAL on the 
SIGNALTHE semaphore; it increments the semaphore counter and checks to 
see that it does not overflow. If there are suspended processes on the 
semaphore, the oldest is taken off the semaphore queue and rescheduled 
(according to its priority) in the same fashion as the procedure 
SIGNAL. If the process is an interrupt handler, it will be placed in 
the active queue as long as it is of equal or numerically lower 
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priority (i.e., equal or higher urgency) to the present head of the 
queue. If the rescheduled process is not put in the active queue, it 
is put on the queue before the last process of the same priority. 


Finally, the context switch is performed and the process on the _ head 
of the ready queue (which may be the rescheduled process) becomes the 
currently executing process. 

EXAMPLE : 


REF WAITSI 


MOV @<ga>,*R10+ PUSH SEMAPHORE “WAITFOR*® 
MOV @<ga>,*R10+ PUSH SEMAPHORE “SIGNALTHE~ 
DATA CALLS 


DATA WAITSI 


EXCEPTION AND CONDITIONS: All the exceptions that occur under SIGNAL 
and WAIT; incorrect priority of a process attempting to WAIT on the 
semaphore WAITFOR, overflow of the semaphore counter SEMOVR in the 
semaphore SIGNALTHE, and an illegal semaphore. 


4.3.8 Function SEMASTate 


This function returns the state of the semaphore, which can be 
O(AWAITED), 1(EMPTY), or 2(SIGNALED). It first initializes the return 
Value to O(AWAITED). It then inspects the semaphore counter field of 
the semaphore record. If this is found to be less than Zero, 
QO(AWAITED) is the correct value to be returned. If the semaphore count 
field equals zero, then the returned value is I1(EMPTY). If the 
semaphore count is greater than zero, then the returned value is 
2(SIGNALED) . ; 


NOTE: The value returned accurately reflects the state of the 
semaphore at the time the function was called, but the state could 
Change immediately thereafter. 


EXAMPLE: 


REF SEMAST 


MOV @<ga>,*R10+ PUSH SEMAPHORE “SEMA~ 
DATA CALLS 

DATA SEMAST 

MOV *R10,@<ga> POP STATE 


EXCEPTIONS AND CONDITIONS: None. 
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4.3.9 Function SEMAVAlue 


This function simply returns the value in the semaphore count field of 
the semaphore record. A positive integer value indicates the number of 
unprocessed (unreceived) SIGNALS to the semaphore. A negative integer 
value indicates the number of processes WAITing on the semaphore. A 
zero value indicates that there are neither unreceived SIGNALS nor 
WAITing processes. 


EXAMPLE : 


REF SEMAVA 


MOV @<ga>,*R10+ PUSH SEMAPHORE “SEMA” 
DATA CALLS 

DATA SEMAVA 

MOV *R10,@<ga> POP SEMAPHORE VALUE 


EXCEPTIONS AND CONDITIONS : None. 


4.4 INTERRUPT ROUTINES 


The routines listed in this subsection (with the possible exception of 
Procedure ASSEMBLYEVENT and Procedure NOASSEMBLYEVENT), are used _ to 
associate semaphores with hardware interrupts and perform necessary 
functions within the interrupt service code. 


When an interrupt occurs, the interrupt handling procedure INTSPC 
searches for processes to handle the interrupt. INT$PC first looks for 
an assembly language event then for any process WAITing on the 
semaphore that has been designated as the primary receiver of 
interrupts at that level by use of the EXTERNalevent procedure. If 
either: 


1) There is no semaphore assigned to that interrupt level as 
a primary receiver, or 


2) There are no processes WAITing on the semaphore which has 
been assigned as the primary receiver of interrupts at 
that level, 


INTSPC looks for a secondary receiver of interrupts by inspecting 
the semaphore associated with that level by use of the 
ALTEXTernalevent procedure. If no processes are found waiting, 
the system will crash. 

Only one primary receiver and one secondary receiver are allowed 
to exist at a time, at any particular interrupt level. 


4.4.1 Procedure EXTERNalevent 
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This procedure designates the semaphore SEMA to be the primary 
interrupt handler at a particular level of interrupts specified 
by the parameter LEVEL. $LVLCK is called to ensure that the 
interrupt level is in the range 1 to 15. LOWERS is called to 
determine if the semaphore is associated with an external event 
and if the process(es) WAITing on the semaphore are of 
sufficiently high urgency to handle an interrupt at the level 
specified by LEVEL. LOWERS also sets the level of the semaphore 
cas of the interrupt if it is associated with an interrupt 
andler. 


LOWERLevel is called a second time to adjust the semaphore level 
field of the semaphore record of any. semaphore that was 
Previously allocated as the primary receiver of interrupts at the 
level specified by LEVEL. It lowers the urgency level to either. 
the level at which this semaphore is attached, or to 32767 (the 
lowest possible level). : 


Because only one semaphore may be attached to a given interrupt 
level as the primary receiver at any one time, this procedure 
effectively does a NOEXTErnalevent at the level specified by 
LEVEL and then attaches a new primary interrupt handler at this 
level. | 


EXAMPLE: 


REF EXTERN 


MOV @<ga>,*R10+ PUSH SEMAPHORE “SEMA*~ 
MOV @<ga>,*R1lO+ PUSH LEVEL (INTEGER) 
DATA CALLS 


DATA EXTERN 


EXCEPTIONS AND CONDITIONS: 


1) The interrupt level is invalid, i.e., outside the range 0-15. 


2) Processes which are already Waiting on the semaphore are 
unable to handle that interrupt level. | 


3) The interrupt level is not allocated a dedicated workspace. 


4) An illegal semaphore is detected. 
4.4.2 Procedure NOEXTErnalevent 


This procedure detaches the semaphore which has been designated 

as the primary receiver of interrupts at the level specified in the 
Parameter LEVEL. In its place, the "No-event" semaphore, NOEVT is 
attached at this level. If no primary receiver semaphore is attached 
to this level, the procedure has no effect. The detached semaphore (if 
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any) has its level adjusted as required by the procedure LOWERS. 
EXAMPLE: 


REF NOEXTE 


MOV @<ga>,*R10+ PUSH LEVEL (INTEGER) 
DATA CALLS 
DATA NOEXTE 


EXCEPTIONS AND CONDITIONS: An exception will occur if the interrupt 
level is outside the range 1-15. 


4.4.3 Procedure ALTEXTernalevent 


This procedure designates the semaphore SEMA to be the secondary 
receiver of interrupts at the level specified by the parameter 
LEVEL. The interrupt level must be in the range 1-15. 


This procedure checks’ for the exception conditions (see below) 
and calls $LVLCK and then LOWERS twice. LOWERS first checks’ to 
see that the semaphore level field of the semaphore record 
indicates that any processes WAITing on the semaphore are of 
sufficiently high urgency to handle an interrupt at the level 
specified by LEVEL. LOWERS then adjusts the semaphore level field 
of the semaphore that was previously attached as the primary 
receiver at this level of interrupts, as necessary. 


EXAMPLE : 


REF ALTEXT 


MOV @<ga>,*R10+ PUSH SEMAPHORE “SEMA 
MOV @<ga>,*R10+ PUSH LEVEL (INTEGER) 
DATA CALLS 


DATA ALTEXT 
EXCEPTIONS AND CONDITIONS: An exception occurs if: 


1) The interrupt level is invalid, i.e., outside the range 
1-15. | 


2) Processes which are already WAITing on the semaphore SEMA 
are unable to handle that interrupt level. 


3) The interrupt level is not allocated a dedicated 
workspace. | | 
4) Illegal semaphore is detected. 


4.4.4 Procedure NOALTExternalevent 
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4.4.4 Procedure NOALTExternalevent 


This procedure detaches a semaphore which is the _ secondary 
receiver of interrupts at the level specified in the parameter 
LEVEL. If no semaphore has’ been previously allocated (by 
ALTEXTernalevent) as the secondary receiver, this procedure has 
no effect. | 


The no event semaphore NOEVT is re-attached to this level. The 
level of interrupt specified in the parameter LEVEL must be in 
the range 1-15. This procedure calls LOWER$, which adjusts’ the 
semaphore level as necessary. 


EXAMPLE : 


REF NOALTE 


MOV @<ga>,*R10+ PUSH LEVEL (INTEGER) 
DATA CALLS 
DATA NOALTE 


EXCEPTIONS AND CONDITIONS: An exception occurs if the interrupt 
level LEVEL is outside the range 1-15. | 


4.4.5 Function INTLEVel 


This function returns a number which indicates the type of SIGNAL 
which activated the process. If the returned value is in the 
range 1-15 then an interrupt of that level activated this 
process. If the value returned is "-1", then activation was by 
another process SIGNALing the semaphore on which this process had 
been WAITing. If the returned value is "0", the process has not 
been suspended and reactivated since it was started. INTLEVel can 
be used by a reactivated process in order to find which interrupt 
level (if any) that activated it. 


EXAMPLE : 


REF INTLEV 


DATA CALLS 
DATA INTLEV 


MOV *R10,@<ga> POP INTERRUPT LEVEL 


EXCEPTIONS AND CONDITIONS: None. 


4.4.6 Procedure MASK 











This procedure is called to disable interrupts. Interrupts remain 
masked until the procedure UNMASK is called. A return from the 
routine which called MASK does NOT remove the mask. The interrupt 
mask, bits 12 to 15 of the status register are set to zero. 


EXAMPLE : 4 | ie 


REF MASK 


DATA CALLS 
DATA MASK 


EXCEPTIONS AND CONDITIONS: None. 


4.4.7 Procedure SETMASK 


This procedure sets the interrupt mask to disable all interrupts 
equal to or less urgent than the interrupt level passed (as 
Parameter NEWMASK) to SETMASK in the calling sequence. The value 
of the previous mask (i.e., the value at which the interrupt mask 
was set prior to calling SETMASK) is returned to the user as an 
output parameter. Specifying 0 as the NEWMASK value, will cause 
all interrupts to be masked Calling SETMASK, specifying the 
Previous mask as the new mask will restore the old interrupt 
setting. NEWMASK must be between 0 and 15 (inclusive). 


EXAMPLE : 


REF SETMASK 


MOV @<ga>,*R10+ PUSH NEW MASK 
MOV @<ga>,*R10+ PUSH PTR TO WORD 
DATA CALLS WHICH WILL BE SET 
DATA SETMASK TO OLD MASK 


EXCEPTIONS AND CONDITIONS: None. 


4.4.8 Procedure UNMASK 


This procedure enables interrupts. It reverses the effect of the 
MASK procedure. The procedure first checks the priority of the 
Current process. If that process is not an interrupt handler 
(i.e., it has a numerical priority of greater than . 15), all 
interrupts are enabled by setting the interrupt mask (bits 12 to 
15 of the status register) to "l’*s". If the process iS an 
interrupt handler, those interrupt levels which are equally or 
less urgent remain inhibited. Level zero interrupts always remain 
enabled. 





EXAMPLE: 


REF UNMASK 


DATA CALLS 
DATA UNMASK 


EXCEPTIONS AND CONDITIONS: None. 


4.4.9 Procedure INTSPC 


This procedure controls interrupt handling. When an _ interrupt 
occurs, control passes to this procedure, which immediately masks 
further interrupts. 


The procedure first checks for ASSEMBlyevent and then determines 
if a process is suspended on the semaphore that has' been 
designated as the primary receiver of interrupts (by 
EXTERNalevent). If no primary receiver of interrupts has_ been 
specified, the semaphore designated as the secondary receiver of 


interrupts is checked (by ALTEXTernalevent). If no processes are. 


found suspended on an interrupt handling semaphore, the system 
crashes. 


If a process capable of handling an interrupt is found, the 
Oldest process is taken off the semaphore queue, and the pointer 
to the next process is moved to the head of the that queue. The 
level of interrupt is placed in the current interrupt field of 
the process record for debug information. The context of the 
Current process is stored and the interrupt handler process is 
moved to the active queue. The context of the interrupt handler 
process is loaded and the interrupt handler becomes the current 
active process. 


NOTE: The user will never need to call this procedure; therefore, 
no example is given. 


EXCEPTIONS AND CONDITIONS: If there is no designated interrupt 
handler at a given interrupt level, the system crashes. 


4.4.10 Procedure ASSEMBlyevent 


When an interrupt occurs, and further interrupts are masked, 
internal data structures are examined to determine whether 
ASSEMBlyevent has been called to associate an assembly language 
handler with the current interrupt. If so, the workspace pointer 
and entry point address passed to ASSEMBlyevent in the calling 
sequence are used as a transfer vector to branch to the handler. 
The interrupt mask is zero when the handler is given control 
(i-e., all interrupts are masked) and must not be modified at any 
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time within that routine. When the assembly language handling of 
interrupts is complete, the user has a choice of action: 


1) If no further processing of this interrupt is 
required, a return is made directly to the interrupt 
workspace by returning control to the interrupted 
routine. This may be done using the following 
sequence: 


LI R14,R 
R RTWP 


This code causes two "RTWP" instructions to _ be 
executed in a row. Note that this code is not 
position independent. If the assembly event handler 
is to be position independent, another method of 
setting R14 to the address of an RTWP instruction is 
to get the routine entry point from the interrupt 
trap address and add the offset of the RTWP from the 
routine entry point: 


PSEG 
ENTRY EQU- $ 
MOV @<level>*4+2,R14 © GET ADDRESS OF ENTRY 
AI _— R14, R-ENTRY FROM INT TRAP AREA 
R RTWP DOUBLE RETURN 


2) If the interrupt should also be processed by the Rx 
interrupt environment, simply execute a single 
"RTWP" instruction. This causes a_ return to the 
point at which the -Rx transfer code would have 
branched had there been no assembly handler. Thus, 
internal data structures are examined to determine 
if an event semaphore has been associated with this 
interrupt level by a call to either EXTERNALEVENT or 
ALTEXTERNALEVENT, and Rx handles the interrupt. 


EXAMPLE: 
MOV @<ga>,*R10+ ADDRESS OF INTERRUPT WORKSPACE 
MOV @<ga>,*R10+ ADDRESS OF INTERRUPT ROUTINE 
MOV @<ga>,*R10+ INTERRUPT LEVEL 
DATA CALL$ 


DATA ASSEMB 


EXCEPTIONS AND CONDITIONS: An exception occurs when a bad 
LEVEL parameter is passed. 
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4.4.11 Procedure NOASSEmblyevent 


This procedure is called to disassociate an interrupt level with 
an assembly language handler. 


EXAMPLE: 
MOV @<ga>,*R10+ LEVEL OF HANDLER TO BE REMOVED 
DATA CALLS 


DATA NOASSE 


EXCEPTIONS AND CONDITIONS: An exception occurs when a bad 
LEVEL parameter is passed. 


4.5 PROCESSOR MANAGEMENT ROUTINES 


These routines are used to reschedule the execution of multiple 
process systems and locate the current process record. 


4.5.1 Procedure SETPRIority 


This procedure modifies the priority of the most urgent, 
non-interrupt process. It ensures that NEWVALUE is in the range 
16-32767 and masks all interrupts, scanning the ready queue and 
active queue for the first non-interrupt handler (i.e., a process 
with a numerical priority greater than 15). If one is not found, 
the parameter OLDVALUE is returned as zero, otherwise the old 
Process priority is returned. The new process priority is then 
loaded from NEWVALUE and compared with the old value. If the new 
value is numerically greater than the old, the procedure SWAP is 
called to re-schedule the process. This routine is used to force 
rescheduling of the most urgent non-interrupt process. 


EXAMPLE : 


REF SETPRI 


MOV @<ga>,*R10+ PUSH ADDRESS OF “OLDVALUE” 
MOV @<ga>,*R10+ PUSH ADDRESS OF “NEWVALUE~ 
DATA CALLS 


DATA SETPRI 


EXCEPTIONS AND CONDITIONS: An exception will occur if the NEWVALUE is 
outside the range 16-32767. 


4.5.2 Procedure SWAP 
This procedure reschedules the current non-interrupt process 


(i.e., the process nearest the head of the ready queue or the 
active ‘process with a priority numerically greater than 15). The 
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process that is being SWAPped is placed in the ready queue behind 
the last process of the same priority. This means that if there 
is more than one process with the same priority as the currently 
active one (and it is a noninterrupt process), a SWAP operation 
will cause a new process to become the currently active one. 


The following example illustrates a swap operation when the 
Current process is resheduled. In this example each process is 
represented by its priority and a letter indicating initial 
sequence. , 


Current process 


Ready queue (before SWAP): 20a 20b 20c 23d 23e 25f 
Ready queue (after SWAP): 20b 20c 20a 23d 23e 25f 


The SWAP operation may be used to allocate execution time slices 
to different processes. This time slicing is implemented by the 
CLKINT process described later. 

EXAMPLE : 


REF SWAP 


DATA CALLS 
DATA SWAP 


EXCEPTIONS AND CONDITIONS: None. 


4.6 MEMORY MANAGEMENT PROCEDURES 

These routines are used to perform dynamic management of the heap 
packets of memory. 

4.6.1 Procedure NEWS 


This process allocates a contiguous area from the current 
process”s heap of LENGTH or more words and returns a pointer to 
the area in pointer. This memory may then be used by the calling 
process until released by use of the FREES procedure. 
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EXAMPLE : 


REF NEWS 

MOV @<ga>,*R10+ PUSH ADDRESS OF POINTER 
MOV @<ga>,*R10+ PUSH “LENGTH” IN WORDS 
DATA CALLS 

DATA NEWS 


EXCEPTIONS AND CONDITIONS: If the heap area cannot be allocated, 
a zero value pointer is returned. 


4.6.2 Procedure FREES$ 


This procedure releases an area of heap allocated by the NEWS 
Procedure. The pointer to the heap packet is passed to this 
Procedure which sets it equal to Zero. 


EXAMPLE: 


REF FREES 


MOV @<ga>,*R10+ PUSH ADDRESS OF POINTER 
DATA CALLS 
DATA FREES 


EXCEPTIONS AND CONDITIONS: None. 


4.7 CLOCK MANAGEMENT ROUTINES 


The clock management routines time events or ensure specific time 
delays in the user’s system. Whenever any real time operations 
are required the user must first start CLKINT process. (Note that 
the Rx clock is NOT a time of day clock, but rather an internal 
timer.) 


4.7.1 Process CLKINT 
This process performs the following three functions: 
1) Initialize the system clock to 00000000 milliseconds, 


2) Provide “time out* signals that a specified time interval 


has occured, with a resolution of n milliseconds per 
interrupt, 


3) Implement time slicing between processes by calling SWAP 


every “n° milliseconds. If “n* is zero, no time’ slicing 
is performed. 














This process must be started whenever a system clock is required. 
There is some processor overhead when using the clock routines, 
and the overhead will increase as the number of time elements 
waiting increases. The overhead is also inversely proportional to 
the number of milliseconds per timer interrupt: the lower the 
numbr of milliseconds per interrupt, the greater the overhead. 


The system clock uses a double integer (32 bits) contained in the 
Clock record. A pointer to the head of a queue of time element 
records is also maintained in the clock record. (Clock and clock 
service records are described in Appendix A). Note that a 
workspace for level three interrupts is provided in the CONFIG 
module by default. | 


Time elements are put on the queue by the TWAIT procedure, and 
may be signaled by other user processes. 


EXAMPLE : 


REF CLKINT 


MOV @<ga>,*R10+ PUSH MILLISECONDS PER INTERRUPT 

MOV @<ga>,*R10+ PUSH MILLISECONDS PER SWAP (IF 0, NO SWAPPING 
MOV @<ga>,*R10+ PUSH 9901 BASE (USUALLY >100) 

DATA CALLS 


DATA CLKINT 


EXCEPTIONS AND CONDITIONS: Must have workspace for level three 
interrupts. 


4.7.2 Procedure TWAIT 


This procedure is used to suspend a process for a specified time 
interval or until another process has signaled an event, 
whichever comes first. This feature is necessary when only a 
certain amount of time can pass before the event should have 
occured (such as I/O). | 


The time interval is a two word, signed positivé integer value. 
The most significant word is pushed first, followed by the least 
Significant word. 


This procedure builds a time element from the parameters it is 
passed, and then proceeds to place it in the clock”s time queue. 
It then performs a WAIT on the semaphore. If the semaphore is 
Signaled by the clock process, it sets the status word to zero 
and returns. If the semaphore was signaled from another’ user 
process (i.e., before the time was up), then the procedure sets 
the status word to one. : 


Note that the resolution of the clock is user-specified in CLKINT 


and therefore a delay request will suspend a process for n ms 
(where “n* is a multiple of the user-specifed clock resolution). 


RETURN CODES : 


0 SIGNALLED 
l TIMED-OUT 
2 THERE WAS ANOTHER WAITER 
3 THE "TIME TO WAIT" IS INVALID, OR THE SEMAPHORE IS INVALID. 
EXAMPLE: 
REF TWAIT 
MOV @<ga>,*R1O+ PUSH THE ADDRESS OF THE SEMAPHORE 
MOV @<ga>,*R10+ PUSH FIRST WORD OF TIME PARAMETER 
MOV @<ga>,*R10+ PUSH SECOND WORD OF TIME PARAMETER 
MOV @<ga>,*R10O+ PUSH THE ADDRESS OF STATUS 
DATA CALLS 
DATA TWAIT 


EXCEPTIONS AND CONDITIONS: The process CLKINT must be started 
prior to the use of this procedure. There must be no other 
processes waiting on the semaphore. 


4.7.3 Procedure DELAY 


This procedure causes the user process to suspend execution for a 
specified number of milliseconds. This delay is achieved by 
calling TWAIT with a specially allocated DELAY semaphore. This 
semaphore is allocated once, and is thereafter re-used by DELAY, 
and is reclaimed by the CLKSTE routine when the process 
terminates. 


EXAMPLE ;: 


REF DELAY 


MOV’ RO,*R1O+ PUSH FIRST WORD OF TIME PARAMETER 
MOV R1,*R10+ PUSH SECOND WORD OF TIME PARAMETER 


DATA CALLS 

DATA DELAY 
EXCEPTIONS AND CONDITIONS: The process CLKINT must be started 
prior to the use of this procedure. 


4.8 ERROR REPORTING PROCEDURE EXCEPTion 


This procedure performs an error trap from a process. The values 
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Of CLASSCODE and REASONCODE are placed in the error fields of the 
caller*’s process record and the run-time support exception 
routine is called. 


EXAMPLE : 


REF EXCEPT 


MOV @<ga>,*R10+ PUSH “CLASSCODE” IN MSB 
MOV @<ga>,*R10+ PUSH *~REASONCODE’” IN MSB 
DATA CALLS 


DATA EXCEPT 


EXCEPTIONS AND CONDITIONS: 
None. 
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SECTION V 


CHANNEL ROUTINES 


5.1 GENERAL 


Rx makes it possible for the user to create and pass messages between 
processes using the concept of channels. Channels can be thought of as 
data structures over which messages (data) can be sent and received by 
processes located at either end (see Figure 5-1). Initialization of 
the channel, construction of the message to be sent, and 
synchronization of the actual message transfer are performed using the 
Channel Routines described in the following subsections. 


In the normal start-up sequence for transmission between producer and 
consumer processes, each process issues a CSINIT on the same _ channel 
name. (A process MUST initialize a channel in order to send messages 
over that channel.) A call is then made to CSALLOC by the process 


sending the message to allocate a heap packet for passing the text 


data. 


PRODUCER CONSUMER 





PROCESS PROCESS 








FIGURE 5-1. PROCESS COMMUNICATION VIA CHANNELS 


The following is a skeletal outline for a typical message transmission 
between producer/consumer processes. For a complete example, see the 
demonstration program in Appendix E. 


SYSTEM: 


REF PRODUC) 
REF CONSUM 


DATA CALLS, PRODUC 
DATA CALLS , CONSUM 
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PRODUCER: 


REF CSINIT 
REF CSTERM 
REF CSALLO 
REF CSSEND 
REF CSWAIT 
<call CSINIT to connect to channel> 
<call CSALLO to allocate message buffer> 
loop: ~ 
<fill message buffer> 
<call CSSEND to send message> 
<call CSWAIT to wait for acknowledgement> 
loop exit: 
<call CSTERM to disconnect fom channel> 


CONSUMER: 


REF C$INIT 
REF C$TERM 
REF C$RECE 
REF CSACKN 


<call CSINIT to connect to channel> 
loop: | 
<call CSRECE to send message> 
<process data in message buffer> 
<call CSACKN to wait for acknowledgement> 
loop exit: 
<call CSTERM to disconnect fom channel> 


In the previous example, the producer first initializes a channel that 
will be used to send the message to the consumer, then allocates 
memory for that message using the cCS$INIT and CSALLO - routines 
respectively. The CSSEND routine actually sends the message to the 
consumer, while CSWAIT will suspend the producer (i.e., the producer 
is placed in a WAIT queue) until an acknowledgement of the message is 
received. (Reference Section 2, 2.3.2 for detailed information on 
semaphore queues.) 


The consumer initializes the same channel as the producer via the 
CSINIT routine and then calls CSRECE to suspend until a message is 
received over the intialized channel. When the message is received, 
the consumer performs whatever action is necessary to process’ the 
data. The consumer may send messages back to the producer by modifying 
the message that was sent. When the consumer’ has processed the 
message, it calls CSACKN to notify the producer that the message has 
been received/processed, and the producer is released from suspension. 
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Finally, when each process is finished, it calls CSTERM to disconnect 
from the channel. When the last process disconnects from a particular 
channel, all message buffers and other data structures associated with 
that channel are freed. 


When dealing with channels, it is important to remember that a channel 
will not exist unless it is designated (named) by a process as 
existing (via CSINIT), and that in order to speak to another process, 
the receiving process must designate (name) the same channel. Two 
terms are used: channel "name" and channel identifier or "ID". The 
name of a channel is a number from 1 to 32767 which is passed to 
CSINIT. CSINIT returns a channel ID, which is a pointer to the channel 
data structure. 


9.2 CHANNEL ROUTINE DESCRIPTIONS 


The following subsections will list and describe each channel routine, 
as well as provide example calling sequences for each. 


5.2.1 Procedure CSACKN 


This routine acknowledges that a message has been received and/or 
processed, and notifies the sending process of that fact. 


CALLING SEQUENCE: 


MOV @<ga>,*R10+ PUSH ADDRESS MESSAGE TEXT POINTER 
DATA CALLS ,CSACKN 


EXTERNAL ROUTINES: CSSHEADER, RTSENTER, RTSEXIT, SIGNAL 


5.2.2 Procedure CSALLO 


The CSALLO routine allocates a heap packet for passing text data 
between processes. The heap packet has a header of fixed size which 
contains information used to synchronize interprocess communication. 
The header is followed by a text data field containing any message to 
be transmitted. The maximum number of characters allowed in the 
message is defined in the first parameter of the calling sequence. 


CALLING SEQUENCE: 
MOV @<ga>,*R10+ PUSH MESSAGE SIZE (INTEGER) 
MOV @<ga>,*R10+ PUSH POINTER TO HEAP PACKET 
DATA CALLS ,C$ALLO : 


EXTERNAL ROUTINES: CSSMSG, RTSENTER, RTSEXIT, CKSEMAPHORE, 
INITSEMAPHORE, TERMSEMAPHORE, HPSFREE, HPSNEW, HPSSYSTEM 








5.2.3 Procedure cecnooeae 

This routine checks that a.message has been sent to a channel. If one 
is present, the routine returns its address. If no message has been 
sent, a message pointer set to nil is returned. 

CALLING SEQUENCE: 


MOV @<ga>,*R10O+ PUSH CHANNEL ID 
MOV @<ga>,*R10+ PUSH MESSAGE TEXT POINTER 


DATA CALLS ,CSCRECE 
EXTERNAL ROUTINES: SETMASK, CSSMSG, RTSENTER, RTSEXIT, CWAIT 


5.2.4 Procedure CS$CWAI 


This routine conditionally waits for a sent message to be 


acknowledged. If the message has been acknowledged, the status word is 
set to TRUE (all ones). If the receiving process does not acknowledge, 
the status word is set to FALSE (Zero). 


CALLING SEQUENCE: 


MOV @<ga>,*R10+ PUSH MESSAGE TEXT POINTER 
MOV @<ga>,*RLO+ PUSH PTR TO STATUS WORD 
DATA CALLS ,CSCWAI 


5.2.5 Procedure CS$DISPose 
This procedure deallocates a channel message. 
CALLING SEQUENCE: 


MOV @<ga>,*R10+ | PUSH MESSAGE TEXT POINTER 
DATA CALLS$,CS$DISP 


EXTERNAL ROUTINES CSSHEADER, RTSENTER, RTSEXIT, TERMSEMAPHORE 
HPSFREE, HPSSYS | 


5.2.6 Procedure CSINIT 


CSINIT searches the channel directory for the channel identified by 
<name>. If the channel is found, CSINIT sets the ID to point to the 
Channel. If the channel is not found, a channel is created, inserted 


into the channel directory, and the ID is set to point to it., If the 
Passed value of <name> is "0", the channel is assumed to have been 


created either in COMMON, or in other memory not declared available to 


the system. Although the channel does not appear in the channel’ 


directory, the routines using ID as an: identifier will operate 
correctly on such a channel. 
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CALLING SEQUENCE: 


MOV @<ga>,*R10+ PUSH CHANNEL NAME 
MOV @<ga>,*R10+ PUSH POINTER TO CHANNEL ID 


DATA CALLS$,CSINIT 
EXTERNAL ROUTINES: RTSENTER, RTSEXIT, CKSEMAPHORE, INITSEMAPHORE, 


SIGNAL, WAIT, HPSFREE, HPSNEW, NPSSYSTEM, MYSMPX 


5.2.7 Procedure CSNOTI 


CSNOTIFY is used to set the channel "Notify" semaphore field to point 
to a user-supplied semaphore. This allows a consuming process waiting 
on a single semaphore associated with several conditions to receive 
notification that a message is present on the channel. The consuming 
process must perform a receive to get control of the message buffer. 
When several channels are used, the consumer can perform a conditional 
receive to determine the location of the message. 


CALLING SEQUENCE: 

MOV @<ga>,*R10+ PUSH CHANNEL ID 

MOV @<ga>,*R10+ PUSH ADDRESS OF SEMAPHORE 
DATA CALLS ,CSNOTI | 


EXTERNAL ROUTINES: None. 


5.2.8 Procedure CSRECEive 


This routine causes a process to suspend until a message is sent to 
the channel. It then takes the message from the channel. and sets <msg> 
to point to that message’s text field. 


CALLING SEQUENCE: 
MOV €@<ga>,*R10+ PUSH CHANNEL ID 


MOV @<ga>,*R10+ PUSH MESSAGE TEXT POINTER 
DATA CALLS$,CS$RECE 


EXTERNAL ROUTINES: C$$MSG, SETMASK, RTSENTER, RTSEXIT, WAIT 


5.2.9 Procedure CSSEND 


C$SEND sends a message to the channel and signals that a message is 
present for processing. The oldest pending CSRECEive on this channel 
will be activated. 


CALLING SEQUENCE: 
MOV @<ga>,*R10+ PUSH CHANNEL ID 
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MOV @<ga>,*R1O+ PUSH MESSAGE TEXT POINTER 
DATA CALLS,CSSEND 


EXTERNAL ROUTINES: CSS$HEADER, RTSENTER, RTSEXIT, SIGNAL | 


5.2.10 Procedure .C$TERM 


This procedure disconnects the calling process from the channel. When | 


the last process is disconnected, the routine closes the data 
structures associated with the channel, terminates the channel pointed 
to by <c>, and updates the directory to reflect the termination. 
CALLING SEQUENCE: 


MOV @<ga>,*R10+ PUSH CHANNEL ID 
DATA CALLS,CSTERM 


EXTERNAL ROUTINES: RTSENTER, RTSEXIT, SIGNAL, WAIT, TERMSEMAPHORE, 
HPSFREE, HPSSYSTEM, MYSMPX 

5.2.11 Procedure CSWAIT 

CSWAIT waits for a message to be acknowledged by a consuming process. 
No further use of the message is allowed until an acknowledgment is 
received from the consumer (via CSACKNO). 


CALLING SEQUENCE: 


MOV @<ga>,*R1O+ PUSH MESSAGE TEXT POINTER 
DATA CALL$,CSWAIT | : 


EXTERNAL ROUTINES: CSSHEADER, RTSENTER, RTSEXIT, WAIT 


5.2.12 Function CSSHEA 

CSSHEADE, given a pointer to a message text field, returns a pointer 
to that message’s header. This function is normally used only by the 
Other channel routines. 

CALLING SEQUENCE: 


MOV @<ga>,*R10+ PUSH MESSAGE HEADER POINTER 
DATA CALLS$,CSSHEA 


EXTERNAL ROUTINES: LOCATION, SIZE 


5.2.13 Procedure CS$SMSG 


CSSMSG, given a pointer to a message header, returns a pointer to’ the 
text field of that message. Upon return, the stack pointer (R10) 
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| 
| 
| 
points to a word containing the address of the text field of the 
message. 
CALLING SEQUENCE: 


MOV @<ga>,*R10+ PUSH MESSAGE HEADER POINTER 
DATA CALLS,CSSMSG 


EXTERNAL ROUTINES: LOCATION, SIZE 
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SECTION 6 


CONFIGURING TARGET SYSTEMS FOR OBJECT CODE EXECUTION 


6.1 GENERAL 


The user has the capability to customize Rx, modeling the system to 
fit his or her application requirements by producing a load module 
that includes the application routines and those processes, 
procedures, and functions supplied in the Rx library that will enable 
the application to execute. 


The link editor of the user’s software development system is used _ to 
create the load module. The configuration process involves giving a 
‘simple description of the target machine to identify ROM/RAM addresses 
and the location of the target machine’s restart vector. The users 
Own interrupt handlers and system crash handler may also be included. 
The result will be a 9900 load module which may be debugged using AMPL 
or the Rx Standalone Debugger. 


The steps required to produce a customized load module will be fully 
explained in following sections. They are: 


1) Assemble user source. ; 

2) Customize and assemble CONFIG. (Section 6.2) 
3) Create a link edit control file. (Section 6.5) 
4) Execute Linkage editor. (Section 6.5.2) 


9) Test using the debugger of the user’s choice. 
(Sections 7 and 8) 


6.2 CUSTOMIZING THE CONFIG MODULE 


Configuration of a target system requires that the user build a 
simple specification of the target machine into the Rx module 
called "CONFIG". CONFIG contains the specification of the 
system’s RAM organization and the locations of the system RESTART 
and LREX vectors. 


NOTE: Because of the symbols used to define the Ram Table, the 
warning message “VALUE TRUNCATED” will be sent to the users 
error file during assembly of CONFIG. The user can ignore this 
message. | . 


Figure 6-1 is the version of CONFIG supplied the user. It 
specifies that RAM is located from >5000 to >A000. Note that this © 
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version of CONFIG may not contain the correct specifications for 
the system being configured. Information on the appropriate 
modifications may be found in following subsections. 











IDT “CONFIG” | | 
IDT “CONFIG” SPECIFY CONFIGURATION 





* REVISION: 08/01/80 1.00 ORIGINAL FOR RX 2.0 
* ROUTINE LIST: CONFIG, IWPSO .. IWP$15, BADSWP, 
* SRAMTB, SRESTA, SLREX, SSYSCR, 
* SDEFAU, SFILL, SSTKSZ, SBOOTP, 
* SIODIR, DBSWP J 
* COPY MODULES: 
* NONE. 
* MACRO DEFINITIONS: 
* NONE. . 
* EXTERNAL ROUTINES: 
* NONE. 
* EXTERNAL DATA: 
PSEG 7 
* MODULE CONSTANTS: 
IWPSZ EQU 24 SIZE OF AN INTERRUPT 
* WORKSPACE (R4-R15) 
LOWRAM EQU >5000 LOW BOUNDARY OF RAM 


* MODULE VARIABLES: 
* 


DORG LOWRAM 
* 

DEF IWPS0O,IWPS$1,IWP$2,IWPS3 

DEF IWPS$4,IWPS$5,IWPS6, IWP$7 

DEF IWPS$8,IWPS9, IWPS$10,IWPS1ll 

DEF IwWPS12,IWP$13,IWP$14,IWPS15 

DEF BADSWP,DBSWP 

IWPSO BSS 32 

IWPS1 BSS 32 

DBSWP EQU IWPS$1 

IWP$2 EQU $-32+IWPSZ 


BSS IWPSZ 
IWPS3 EQU $-32+IWPSZ 
BSS IWPSZ 
IWPS$4 EQU $-32+IWPSZ 
BSS IWPSZ 
IWPS5 EQU $-32+IWPSZ 
BSS IWPSZ 
IWPS6 EQU $-32+IWPSZ 
BSS IWPSZ 
-IWPS7 EQU $-32+IWPSZ ; 
BSS IWPSZ 
IWPS8 EQU $-32+IWPSZ 
BSS IWPSZ 


FIGURE 6-1. CONFIG MODULE (Sheet 1 of 4). 





IWPS9 EQU $-32+IWPSZ 


BSS IWPSZ 
IWPS$10 EQU $-32+IWPSZ 
BSS IWPSZ 
IWPS11 EQU $-—32+IWPSZ 
BSS IWPSZ | 
IWPS12 EQU $-32+IWPSZ 
BSS IWPSZ 
-IWP$S13 EQU $-32+IWPSZ 
BSS IWPSZ 
IWP$S14 EQU $-32+IWPSZ 
BSS IWPSZ 
IWPS15 EQU $-32+IWPSZ 
BSS IWPSZ 


BADSWP BSS 32 
* 
LOWHP EQU S$ 
*& 


RORG 
oe “CONFIG: SPECIFY CONFIGURATION” 
ABSTRACT: 

SPECIFY CERTAIN SYSTEM PARAMETERS, THE RAM 

CONFIGURATION,. AND THE I/O SUBSYSTEM 

DIRECTORY. 

CALLING SEQUENCE: 

NONE. 

EXCEPTIONS AND CONDITIONS: 

NONE.. 

LOCAL DATA: 
NONE. 
ENTRY POINT: 

NONE. 
REEKKRAEKEKKRKRRRKRKRKRKKKERRKRKRRKRKRKKKRKRKEKRKKKKRKRKRKKKKRRKRRKKKRRKRKRKRKRKRKRKRER 
* ADDRESS OF THE "BLWP" VECTOR FOR RESTARTS; USE "0" FOR 
* LEVEL 0 INTERRUPT, ">FFFC" FOR THE "LREX" VECTOR, OR 
* THE ADDRESS OF A USER-DEFINED VECTOR. 
rEeEeREEREE EERE ESL ERASE SEES SES EES E EEE EERE REESE EEE EER SEE SEE TEES SY 

DEF SRESTA 
SRESTA DATA 0 


+e te + + + + FH H 
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KREKEKKEKKKKKEKEKKKKKEKEKEEKEETEEKEKKEKKKEEKEEKEEKEKKKEEEKEEEEKREKESE 


* ADDRESS OF THE "BLWP" VECTOR FOR THE "LREX" INSTRUCTION; 
* USE "0" IF THERE IS TO BE NO "LREX" VECTOR OR IF HIGH 
* MEMORY IS ROM. 


» KREEKEKEKKEKEEEEKKEEEKEEEEKEEKKEEEREKKEKEEEEEEKKKEREKEKEEEEKKEKKEKEESE 


DEF SLREX 


SLREX DATA 0 
KKEKKRKKERKEEEKKEKEKEKEEEEK KKK EEREEKIKREEEKEKEEREEKEEEEKEEREE 


'* ADDRESS OF THE USER-DEFINED ROUTINE TO BE INVOKED IN CASE 


* OF A SYSTEM CRASH: USE "0" FOR THE SYSTEM DEFAULT WHICH 

* IS TO MASK INTERRUPTS AND IDLE THE PROCESSOR. 

KKEKKKEKKEKKEEKEEEKEEEEEKEKEREKKEKEEEEEEKEEKEEKEKEREEKEEKEEKREEE 
DEF S$SYSCR 

SSYSCR DATA 0 

HKEEEKEKEEKEEEEKEEKEKEKREKEKEKEKKEERREKREKEEKEEEKEKEKEKEEKREKEESE 

* ADDRESS OF THE MPP ROUTINE TO BE INVOKED IF AN EXCEPTION 

* OCCURS BUT NO EXCEPTION HANDLER HAS BEEN SPECIFIED: USE 

* "0" FOR THE SYSTEM DEFAULT WHICH IS A "NO EXCEPTION 

* HANDLER" SYSTEM CRASH. 

HHKKKKEKKKKKEKKEKKKEEKKREKKRERREKREEKREEKEEEEEEEKEEEEKEEKEEKKEERKEEERES 


DEF S$DEFAU 


‘SDEFAU DATA 0 


KKEKKKKEKKKEKEKEKEKEKEKKEEEEEEEEKEKEEEKREEKEEKEEEREKKKEKEKES 


* THIS IS THE VALUE WITH WHICH THE HEAP WILL BE 

* INITIALIZED AT POWER-UP. 

KEKEKEEKKEKEEEKEKEKREKREEKEEKEKEREREEEKEKEKEKEEAEEKKEKEEKEREERER 
DEF SFILL 

SFILL JMP §$ | 

KKEKKKEKEKKEEEKEEEKEKEEEKEEEEEEAEEKEEEKEEEREEKREEKEEEEEEEEKEKEKEEE 

* THIS IS THE DEFAULT STACK SIZE (IN WORDS) THAT IS USED 

* IF A "STACKSIZE" CONCURRENT PARAMETER IS NOT SPECIFIED. 

KKEKKEKKEKKKE KEKE KEKE 
DEF SSTKSZ 

SSTKSZ DATA >100 

KHHKEKKRKEKEKEKEKKEKAEKKEKEKKKEREEKEKEEREKEKREEEEKKKEEKEKREKEEEKEKREE 

* THE PARAMETER LIST FOR THE CALL TO "SSPRCS" TO START THE 

* "BOOT" PROGRAM. | 

KKKKKEKKEREKKEKEKKEKEKREREKEEEEREEEEKREKKEEEEEKEKEKEEKEEAEERE 


DEF $BOOTP 


SBOOTP DATA >0000 FRAME SIZE 
DATA >0000 LEXICAL NESTING LEVEL 
DATA >0000 PRIORITY 
DATA >0100 3 STACK SIZE 
DATA >0000 HEAP SIZE 


FIGURE 6-1. CONFIG MODULE (Sheet 3 of 4). 
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* ADDRESS OF THE "RAM TABLE," THE TABLE THAT DESCRIBES THE 
: REGIONS OF READ-WRITE MEMORY TO BE COLLECTED INTO THE 
HEAP. 
KEKEKKEKKEKREKKRKKRKKKKRKKRKKRKKR KKK KKK KKK 
DEF S$RAMTB 
SRAMTB DATA RAMTB 
REKKKEKREKRRKRRRRKRKRKRKRKRRRKR KKK KKK KKK KKK 


* ADDRESS OF THE DIRECTORY OF I/O SUBSYSTEMS. 
PE RES EAEESRESE REL E EERE SEE SLE REESE ERE RARER ERARRESREEESEARSESESRERE RES SEY 
DEF SIODIR | : 
SIODIR DATA IODIR 
KKERKRERKRKRRKRRKERKRKRKKRKKRKKRKRKKRKKRRKRKRKKKKKKRKKAKRKEKKKRERKKRKKEKEKKKREE 
* THE FOLLOWING TABLE IS A LIST OF "LENGTH _IN BYTES, 
STARTING ADDRESS" PAIRS THAT DEFINE THE RAM TO BE USED 
BY THE EXECUTIVE; A WORD OF "0" TERMINATES THE LIST. 
THE RAM REGIONS MUST BE IN ASCENDING ORDER AND MUST NOT 
OVERLAP. 
KREKEKKEKKRKRRERRRRKRRKERARKRKRKRKEKRKKKRKRKRKRKRKKKRKKRKRKKKRKRKRKKRKKRKRRKRKRKRKRRKRKRE 
RAMTB DATA >A000-LOWHP, LOWHP 
DATA 0 LIST TERMINATOR 
‘ORO ERCESERERERERERERESSE EERE SESE SESE SESE STEERER EEE EEE SE! 
* THE FOLLOWING TABLE IS A LIST OF "SERVICE DIRECTORY, 
* PORT CONSTANTS" PAIRS THAT DEFINE THE I/O SUBSYSTEM TO 
* BE INITIALIZED WHEN ROUTINE "DSINIT" IS CALLED; 
* A WORD OF "0" TERMINATES THE LIST. 
KRKEEKRKRRKEKRKRKRKRKRRRKKKRKRKKRKEKRKRKRKRKRKRKRKRKKRKKKRKRKKKRKRKRKKKKKRRKRKRKRKKKKRKRKR KKK 


IODIR EQU S$ 
* 


+ + + 


= INSERT LIST ENTRIES HERE. 
* 

DATA 0 LIST TERMINATOR 
* 

END 


FIGURE 6-1. CONFIG MODULE (Sheet 4 of 4). 











6.2.1 Specification of System Parameters 


A number of target system parameters have been collected into 
CONFIG so they can be conveniently modified by the user. Each 
parameter is described in one of the following paragraphs. . 


Parameter SRESTA is a data word that contains the address of a 
transfer vector for a BLWP instruction that will be executed if 
the procedure RESSTART is invoked. A value of "0" will cause a 
level 0 interrupt to be simulated; a value of ">FFFC" will 
simulate a LREX instruction. Special restart processing may be 
specified via a user-defined transfer vector. 


An LREX instruction causes a trap through the transfer vector at 
location >FFFC; it is often used for reloading or “warm starting" 
a system in which the level 0 interrupt is used for a power-up or 
"cold start". If high memory is in RAM, then the LREX vector must 
be initialized at run-time. If the data word $LREX contains a 
non-zero value, it is interpreted as the address of a _ (ROM) 
transfer vector that Rx will copy to >FFFC through >FFFF during 
system initialization. If the data word is 0 (i.e., high memory 
is ROM, or no LREX instructions will be used), no copy will be 
made. 7 


' Parameter S$SYSCR permits the user to specify the action to be 
taken if a system crash occurs. A non-zero value of the data word 
SSYSCR is interpreted by the Executive Run Time Support as the 
address of an assembly language routine that will be invoked (via 
a BL instruction with register RO containing the crash code) in 
case of a unrecoverable error. A value of zero results in a 
default routine being invoked that masks all interrupts’ and 
executes the IDLE instruction. 


Parameter SDEFAU permits specification of a default exception 
handler that will be invoked if an exception occurs in a process 
for which no exception handler has been established. If a default 
is to be used, then the data word $DEFAU must contain the entry 
point address of that routine. A value of Zero will cause a "no 
exception handler" system crash to occur. 


The value in the data word S$FILL is the pattern with which the 
heap will be initialized at power-up; the suggested yalue is’ the 
instruction "JMP $" (Hex value >lOFF) which will sometimes stop 
errant execution. | | 


Parameter $STKSZ is the default stack size (in words) that will 
be used if a "stacksize" concurrent parameter is not specified 
for process. To do this, the process start code (see 4.1.5) needs 
to be changed to this: 








REF SSPRCS 


MOV @<ga>,*R10+ PUSH FRAME SIZE IN BYTES 
MOV @<ga>,*R10+ PUSH LEXICAL LEVEL 

MOV @<ga>,*R1O+ PUSH PROCESS PRIORITY 
MOV @SSTKSZ,*R1LO+ USE DEFAULT STACK SIZE 
MOV @<ga>,*R10+ PUSH HEAP SIZE IN WORDS 


The five words labeled $BOOTP are the parameters to the process 
Creation routine SSPRCS that creates the "boot" program. The 
Executive Run Time Support begins execution in a program that 
"bootstraps" the system into execution by initializing system 
data structures and then invoking the "ghost" procedure GHOSTS 
which the user must customize to perform application dependent 
initialization and start the user“s system (Section 6.3). Since 


the Processing that is performed in the boot program is. 


application-dependent, its stack size parameter in the S$BOOTP 
Parameter list may have’ to be adjusted by the user; the other 
four parameters will not require modification. (Since the stack 
region of the boot program will be reclaimed when procedure 
GHOSTS returns and the program terminates, the estimated stack 
size need not be exact.) 


Parameter SRAMTB is a data word containing the address of the 
"RAM table" that is described in the following subsection. 


Parameter SIODIR is a data word containing the address of the I/0 
subsystem directory that is described in 6.2.3. 


6.2.2 Specification of RAM Locations 


The module CONFIG contains a two part description of RAM of the 
target system. The symbol LOWRAM must be equated to the low 
boundary of RAM that is to be managed by Rx. The first part of 
the RAM description declares static data structures that are not 
to be included in the heap. This area begins at LOWRAM and 
contains interrupt and XOP workspaces. Any user-declared static 
(not COMMON) storage (e.g., LREX workspace) should be declared 
following these structures but preceding the symbol LOWHP which 
marks the end of the static data area and the beginning of the 
dynamically allocated heap area. The "RAM table" is a structure 
that contains the addresses and sizes of regions of RAM that are 
to be used for heap allocation. Each region is described by a 
Pair of values, the first of which is the size of the segment and 
the second is its beginning address; a size of zero terminates 
the list. (Regions must be in ascending order and must not 
Overlap.) The RAM table for a target system with RAM from Hex 


addresses >4000 to 9FFF, and >F000 to >FFFF looks like Figure 














RAMTB DATA >6000,>4000 4000 - 9FFF 
DATA >1000,>F000 FOOO - FFFF 
DATA 0 


i . oo: 


FIGURE 6-2. SIMPLE RAM TABLE 


Figure 6-3 shows how this RAM table would be incorporated into 
CONFIG so the static area would be allocated from the first RAM 
region. The expression ">AO0Q-LOWHP" calculates the space 
remaining in the first region after the static areas are 
allocated. 


LOWRAM EQU »>4000 


-DORG LOWRAM 
* 


IWPSO BSS 32 

LOWHP EQU S$ 

RAMTB DATA >A000-LOWHP, LOWHP 
DATA >1000,>F000 
DATA 0 


FIGURE 6-3. USE OF RAM TABLE IN CONFIG MODULE. 


COMMON regions of memory may be used by more than one routine’ to 
eliminate the passing of certain parameters. This may be done 
using the CSEG assembler directive. Common regions must exist in 
regions of RAM outside the Rx system heap to ensure the executive 
cannot allocate the region for other purposes. Therefore, CONFIG 
must not include any memory to be used as a common’ region; the 
value equated to COMMON should be changed so that memory for the 
common is not included in the RAM table, and the link control 
file (described in 6.5.1) should be changed to specify to specify 
the beginning of RAM. 


Use of COMMON is not generally regarded as good programming 
practice, and should be avoided if possible. . 


6.2.3 Specification of the I/O Subsystem Directory 


In his GHOSTS procedure, the user has the option to include a. 


call to Procedure DSINIT, causing automatic initialization of I/0 
subsystems at power-up. The specific subsystems to be initialized 
must be enumerated in the I/O directory table in CONFIG. Each 
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subsystem is described by a pair of values. The first is the 
address of the service directory that defines the entry points of 
those routines that provide subsystem services. The second value 
is the address of the "port constants" associated with the 
subsystem. The directory is terminated by a value of zero where a 
service directory address is expected. 


Figure 6-4 depicts a sample I/O subsystem directory that will 
cause two subsystems to be initialized automatically. A 
record-oriented terminal subsystem is specified by its service 
directory (T0O2$SD) and port constants (TO2$PC). The interprocess 


communication subsystem is specified by its service directory 
(IPCSSD) and a NIL (0) port constants address. 


ae EQU §$ 


REF 102$sp, TO2SPC 
DATA TO2SSD,TO2SPC 


REF IPCSSD 
DATA IPCSSD,0 


DATA 0 LIST TERMINATOR 


FIGURE 6-4. I/O SUBSYSTEM DIRECTORY. 


6.2.4 Example CONFIG Module 
As an example consider the following system: 
1) RAM in locations >B000 to >BFFF and >p000 to >DFFF 


2) ROM. in locations >0000 to >9FFF, >Cc000 to >CFFF and 
>FFOO to >FFFF | 


3) A user-defined restart routine. This routine 
requires a workspace (BGNSWP) and has an entry point 
(BGNSPC) . 


4) I/O subsystems for terminal communication and 
interprocess communication. : 


Figure 6-5 shows how the pertinent portions of CONFIG might be 
specified for this system. | = 








LOWRAM EQU >BO0O0O0 LOW BOUNDARY OF RAM 
IWPSO BSS 32 


BADSWP BSS 32 
* 

BGNSWP BSS 32 
* 

LOWHP EQU §$ 
* 


DEF SRESTA 

SRESTA DATA RESTA 

SRAMTB DATA RAMTB 

SIODIR DATA IODIR 

RAMTB DATA >C000-LOWHP, LOWHP 
DATA >1000,>p000 . 
DATA 0 LIST TERMINATOR 


IODIR EQU §$ 
* 


REF TO2S$SD,TO2$PC 
DATA TO2SSD,TO2$SPC 


REF IPCSSD 
DATA IPCSSD,0 


DATA 0 LIST TERMINATOR 


RESTA DATA BGNSWP,BGNSPC 
REF BGNSPC 


FIGURE 6-5. EXAMPLE CONFIG MODULE. 


The RAM table of Figure 6-5 reflects the two RAM memory segments. 
Notice that the ROM memory segment addresses have no effect on 
CONFIG. The workspace BGNSWP has been declared in the static area 
of CONFIG, and the word $RESTA now points to the transfer vector 
labeled RESTA. 


The variable length and user-defined structures have been added 
at the end of the ROM section of CONFIG. This is done to enable 
changes to be made to these structures without requiring that 
ROMs be reconstructed that reference the CONFIG module. 
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6.3 CUSTOMIZING THE "GHOST" PROCEDURE 


Rx begins execution in a program called BOOTS that "bootstraps" 
the system into execution by initializing system data structures 
and then invoking the "ghost" procedure GHOSTS. The ghost 
procedure is obligated to START the user“s SYSTEM module; it may 
be customized to perform application-dependent initialization. 
Figure 6-6 lists the default version of GHOSTS that is supplied 
with the Executive Run Time Support. (Procedure DSINIT is part of 
the File I/O subsystem components. This procedure will only need 
to be called if File I/O subsystems will be supported. (Reference 
the Device Independent File I/O Package manual, MP386 for 
detailed information). Procedure MSGSINIT is called to identify 
the pathname of the device that is to receive the output of the 
standard procedure MESSAGE. The "start systm$" statement 
activates the user’s system since all system modules are given 
the entry point SYSTMS. 


For most applications the default version of GHOSTS will be 
adequate. If certain initialization must be performed for a class 
of applications (e.g. special devices that must be initialized), 
it is appropriate that it be performed in the ghost procedure so 
it need not be repeated in each application. If it is known that 
I/O will not be used, then a slight saving in code space can be 
made by removing the calls to DSINIT and MSGSINIT in GHOSTS. (If 
the I/O support library is not specified at link edit time, 
DSINIT and MSGSINIT will be resolved by "dummy" routines’ that 
perform no processing.) 











IDT “GHOSTS *” 08/01/80 11:18:47 
* 
* 
DEF GHOSTS 
REF DSINIT 
REF MSGSIN 
REF SyYSTMS 
REF CALLS 
REF EXITSP 
* LC HEX CHAR 
PSEG 
GHOSTS EQU $ 
PR EQU- R7 
CODE EQU- RB 
LF EQU R9 
SP EQU- R1O 
LO EQU S$ 
DATA L0014-L0 
DATA L0036-L0 
DATA >0008 0004 0008 7 
DATA >0008 0006 0008 oa 
DATA >4F50 000A 4F50 OP 
‘DATA >4552 000Cc 4552 ER 
DATA >4154 O00E 4154 AT 
DATA >4F52 0010 4F52 OR 
D0012 DATA >0008 0012 0008 ei 
* LC WORD (S) 
L0014 EQU § 
DATA CALL$,DSINIT 0014 | 
MOV CODE,R1LS5 0018 c3c8 
AI R15,>000A 001A 022F 000A 
MOV LF,R12 O01E c309 
MOV. *R15+,*R12+ 0020 CF3F 
MOV *R15+,*R12+ 0022 CF3F 
MOV *R15+,*R12+ 0024 CF3F 
MOV *R15+,*R12+ 0026 CF3F 
MOV LF, *SP+ 0028 CE89 
MOV @p0012—-L0 (CODE) , *SP+ 002A CEA8 0012 
DATA CALLS ,MSGSIN 002E | 
DATA CALLS$,SYSTMS$ 0032 
L0036 EQU S$ 
=&B @EXITSP 0036 0460 0000 
END. 











FIGURE 6-6. DEFAULT VERSION OF PROCEDURE GHOSTS. 


6.4 ASSEMBLY LANGUAGE INTERRUPT HANDLERS 
RX permits’ the user to handle interrupts in an efficient manner 


using Procedure ASSEMBLYEVENT. ASSEMBLYEVENT allows aé_e specific 
assembly language routine to be given control when a particular 
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interrupt occurs. This routine has two methods by which to 
relinquish control after the interrupt has been handled. One 
causes the interrupt process to be resumed; the other causes’~ the 
interrupt to be propagated to a routine in the Rx environment. 
This capability is designed to permit assembly language handlers 
to accumulate data associated with high frequency interrupts 
until it is appropriate to invoke a higher level handler. Using 
ASSEMBLYEVENT, interrupts can be handled in approximately 1/5 the 
amount of time normally required for interrupt handling (see 
Section 4, 4.3.7 for detailed information on Procedure 
ASSEMBlyevent). 


6.5 LINKING THE APPLICATION SYSTEM 


The Link Editor enables the user to link together only the 
modules which are required by the target application. 


6.5.1 Control File Creation 


A link control file must be created to input to the Link Editor, 
which specifies what application routines to link together and 
the location of the Rx Run-Time Support library. The link edit 
control file is created utilizing the source editor of the users 
development system. 


A sample link control file is included with each different 
version of Rx. This file specifies the file names of the user“s 
application and CONFIG modules, and the file names of the Rx 
Kernel and libraries. 


These must be specified in the following order: 


1) INCLUDE The kernel RXKERN for normal processing, or 
DBKERN to use the standalone debugger. 


2) INCLUDE the optional .stream-lined ESPRCSO process 
termination routine, if desired. This routine provides 
faster process termination at the expense of less 
thorough resource reclamation. | 


3) INCLUDE the user routines and CONFIG module in any 
order desired. If a customized version of GHOSTS is to 
be used, it should also be included here. 


4) FIND the standard Rx routines needed in RX1lOBJ. 

5) FIND the channel routines needed in CHNOBJ. If 
channels are not being used, this step may be left out 
for a slightly faster link edit. 

6) FIND the clock management routines needed in CLKOBJ. 


As with the channel routines this step may be left out 
if the clock is not being used. faster link edit. 
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7) Finally, FIND the Rx support routines in RX20BJ. 


This 


must be the last step, because the standard routines, 
channel routines, and clock routines reference symbols 
defined in this library. 





A template for the Link Edit Control File is presented below. 





Detailed information regarding the format and instructions used 
can be found in the user manuals for the respective link editors. 
SYMT 
TASK <system name> : Name of load module 
INCLUDE <device or volume>.RXKERN ; Or DBKERN 
INCLUDE <device or volume>.EPRCSO : Optional ESPRCS routine, 
: use only with RXKERN 
INCLUDE <device or volume>.<config> ° Configuration Module 
INCLUDE <device or volume>.<user app> ¢ As many as needed 
FIND <device or volume>.RXlOBJ ; Standard Routines 
FIND <device or volume>.CHNOBJ e Channel Library 
FIND <device or volume>.CLKOBJ ¢ Clock Library 
FIND <device or volume>.RX20BJ e Optional Routines 
END 


- 


FIGURE 6-7. SAMPLE LINK EDIT CONTROL FILE. 


In this example, <device or volume> stands for whatever pathname 
information. is needed to accesss the specified file. A sample 
link control file, as well as a description of the files included 
in the release, is shipped with each copy of Rx. 


If the Rx Standalone Debugger will be used, the user“s’' Link 
Control file should include a reference to the DBKERN module 


rather than the RXKERN module. as shown in Figure 6-8. 


SYMT 

TASK <system name> * Name of load module 
INCLUDE <device or volume>.DBKERN ° Or RXKERN 

INCLUDE <device or volume>.<config> e Configuration Module 
INCLUDE <device or volume>.<user app> e AS many as needed 
FIND <device or volume>.RXlLOBJ - Standard Routines 
FIND <device or volume>.CHNOBJ - Channel Library 
FIND <device or volume>.CLKOBJ * Clock Library 

FIND <device or volume>.RX20BJ : Optional Routines 
END 


FIGURE 6-8. SAMPLE LINK EDIT CONTROL FILE 
(USING STANDALONE DEBUGGER) . 


Often, the target system will contain a combination of RAM .and 
ROM. All data and common segments within the application must be 
in RAM. The link edit control file must specify to the linkage 
editor where to place the different types of program segments. 
This can be accomplished through the use of the PROGRAM and DATA 
link editor commands. The PROGRAM command is used to specify 
where all procedure segments (designated via PSEG assembler 

directives) are to be placed. This command should be used to 
specify the starting address of ROM. The DATA command is used _ to 
specify where all data segments (designated via the DSEG 
assembler directive) are to be placed. This command should be 
used to specify the starting address of RAM. All common segments 
(designated by the CSEG assembler directive)are automatically 
Placed following ay data segments, unless specifically located 
using the COMMON command. Figure 6-9 illustrates the use of 
PROGRAM and DATA commands in which ROM starts at address Zero and 
the value >MMMM is the start address of RAM. 


SYMT 

TASK <system name> Name Of load module 
PROGRAM >0 Starting address of ROM 
DATA >mmmm Starting address of RAM 


or DBKERN 
Configuration Module 
As many as needed 


INCLUDE <device or volume>.RXKERN 
INCLUDE <device or volume>.<config> 
INCLUDE <device or volume>.<user app> 
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FIND <device or volume>.RXlOBJ Standard Routines 
FIND <device or volume>.CHNOBJ Channel Library 
FIND <device or volume>.CLKOBJ Clock Library 
FIND <device or volume>.RX20BJ Optional Routines 
END ; 


FIGURE 6-9. SAMPLE LINK EDIT CONTROL FILE 
(SPECIFYING RAM/ROM PARTITIONING) . 


6.5.2 Link Editor Execution 


Once the link edit control file has been created using the 
development system’s text edit facilities, the link editor must 
be executed using the link control file as input. The link editor 
will include the application modules along with only those 
modules of Rx necessary for the application system to operate. 


There should be no unresolved references listed in the _ link 
editor listing output. If unresolved external references are 
detected by the link editor, the link control file should be 
rexamined to insure that all the user modules and the correct Rx 
libraries have been supplied. 





6.6 TARGET (CONFIGURED) Rx APPLICATION 


Upon completion of Link Editor execution, the specified output 
file will contain the final target application object module. 
Figure 6-10 reiterates all the steps necessary to produce an Rx 
load module. The module can now be tested and debugged using 
either the Rx Standalone Debugger or AMPL. These debugging 
methods are described in the following two sections. 
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FIGURE 6-10. PRODUCING AN Rx LOAD MODULE. 
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SECTION 7 


THE Rx STANDALONE DEBUGGER 


7.1 GENERAL 
This section describes the purpose, capabilities, and use of the 
standalone debugger supplied with Rx. The standalone debugger is 
designed to be included in the Rx target system software to aid in 
testing and locating errors. After the software has been debugged, the 
Standalone debugger software can be removed from the system to reduce 
code size, or it can remain to assist in field testing or other 
software maintenance. : 
‘The standalone debugger supplies the fundamental tools necessary to 
debug concurrent and non-concurrent software which may be either ROM 
Or RAM resident. Its commands and messages are very simple in order to 
conserve memory requirements. The standalone debugger offers the 
following features: 

o Inspect/change/dump memory contents 

Oo Inspect/change CRU data 

Oo Inspect/change hardware registers (WP, PC, ST) 

oO Map concurrent processes 

© Display process record 

o Set and unset process entry traps 

Oo Trace concurrent process scheduling 

o Trap on process creation 

Oo Set and clear instruction level breakpoint 

o Simulate interrupts 

Oo Single/multi-step execution 

O Error reporting and recovery 

oO Operates with most standard data terminals 
The standalone debugger package requires 1780 bytes of procedure space 


and 56 bytes of data space. It communicates interactively with the 
operator via a data terminal connected to the target system. The 
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monitor may be entered at power-up, via interrupt level one, via _ the 
load interrupt, or called directly by the application software. A 
momentary switch connected on the backplane of the target system 
chassis can be used to supply either the level one or load stimulus. 
If RAM is located in high memory, the load vector will be used by the 
debugger and may not be used by the application software. 


7.2 CONFIGURING A TARGET SYSTEM 


Certain modifications must be made to the Rx software system to allow 
the use of the standalone debugger. These are including DBKERNEL 
(rather than RXKERNEL) and the debugger in the linked system, and 
supplying a data terminal at the proper I/O connector. 


7.2.1 Link Control File 


Figure 7-1 shows a typical link editor control file for an Rx _ system 
with debugger. INCLUDEd in the control file is the CONFIG module, the 
debug version of the the kernel (DBKERNEL), and the application object 
modules. | | 


SYMT 

TASK <system name> 

INCLUDE <device or volume>.DBKERN 
INCLUDE <device or volume>.<config> 
INCLUDE <device or volume>.<user app> 


Name of load module 
Or RXKERN 
Configuration Module 
As many as needed 


™@ me “0 we BO BQ WO WE 


FIND <device or volume>.RX1lOBJ Standard Routines 
FIND <device or volume>.CHNOBJ Channel Library 
FIND <device or volume>.CLKOBJ Clock Library 
FIND <device or volume>.RX20BJ Optional Routines 
END 


FIGURE 7-1. LINK CONTROL FILE (WITH DEBUGGER) 


7.2.2. Data Terminal 


A data terminal is needed by the standalone debugger for command entry 
and message display. Most asynchronous data terminals including 
teletypes, TI Silent 700 series terminals, and CRT type terminals with 
an EIA interface may be used. The data transfer rate of the terminal 
is sensed at power-up and is automatically set. The allowable data 
transfer rates are listed in Table 7-1. If a 1200 baud terminal is 
sensed, characters are output at a rate of 30/SEC to allow use with 
certain TI Silent 700 series data terminals. Character format consists 
of a start bit, 7 data bits, even parity bit, and two stop bits. 


The standalone debugger software is designed to communicate via the 


main port on either a TM990/101 or 1TM990/100 microcomputer module. If 
using a custom configuration, this corresponds to a TMS9902 
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Asynchronous Controller located at a software CRU base of >80. 


TABLE 7-1. . ALLOWABLE DATA TRANSFER RATES 


19200 baud 
9600 baud 
4800 baud 
2400 baud 
1200 baud* 

600 baud 
300 baud 
110 baud 


* Actually transfers characters at 
30 char/sec 


7.3 USING THE DEBUGGER 


The RX Debugger serves as an interface between the user and the user“’s 
application system. As such, it allows the user to selectively display 


information about the state of a target system in execution and/or 


halt the target system to further examine or modify its environment. 
This section describes how to use the Rx Debugger to debug a target 
system which has been configured as in Section 6.2. 


7.3.1 Getting Started 


The Rx Debugger is given control of the target system when the system 


is first powered-up, and upon RESET. To initialize the system, the 
user should enter a carriage return to set the baud rate for the 
terminal being used. The Debugger will then respond with the heading 


**RX2.0 STANDALONE DEBUGGER** 


and wait | 

for a command to be input. Once the system has been initialized, the 
debugger may be reentered by an interrupt level one stimulus or, if 
high memory is RAM, by a LOAD stimulus. Either of these may be 
supplied by means of a ‘momentary switch connected between the 
corresponding terminal and ground on the chassis backplane. The 
debugger responds with a "?" prompt upon reentry. : 


Whenever the Rx executive software detects an error condition, the 


debugger is entered and the message "ERR= nnnn" is issued. "nnnn" is 


the Rx error code detected. (Appendix B lists the Rx error codes.) If 


the momentary switch is not debounced, the switch may cause a spurious 
interrupt for which the system prints the message "ERR=nnnn". The 
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error code “nnnn* has no meaning in this instance, and the debugger 
returns the *?* prompt. The “GO* command given at this point would 
cause the system to idle. Therefore, a level 0 interrupt should be 
supplied in order to reinitialize the system. (This can be’ simulated 
using the debugger command “SIMI 0*.) When the system is 
reinitialized, the “GO” command returns to the debugger, and _ the 
heading and prompt are again shown. | 


7.3.2 Commands 


The commands implemented by the Rx Debugger fall into’ three 
categories: an informatory message command (TP), system inspection and 
modification commands (IM, IC, IR, PD, SIMI and DAP), and control of 
execution commands (SC, ABP, DBP, SB, CB, GO and IS). The informatory 
message command (TP) displays information about the system in 
execution but does not halt the system or otherwise affect its © 
execution. The system inspection and modification commands’ display | 
information about a target system which has been halted and allow the 
user to modify its environment. The control of execution commands 
provide means for the user to selectively halt a target system and 
return to the Debugger. Any output provided by the debugger can be 
prematurely terminated by pressing the escape key of the data 
terminal. This causes the "?" prompt to be issued for a new command. 
The escape key can also be used to terminate entry of an improperly 
typed command or parameter. 


The Rx Debugger implements the following commands: 


SC <flag> Set Process Creation Trap 

TP <flag> Trace Process Scheduling 

IM <addr,addr> Inspect/Modify/Dump Memory 

IC <base,width> Inspect/Modify CRU 

IR Inspect/Modify Hardware Registers (WP, PC, ST) 
PD <addr> Process Record Dump 
DAP Display All Processes 

ABP <addr> Assign Process Breakpoint 

DBP <addr> _—_— Delete Process Breakpoint 

SB <addr> Set Breakpoint 

CB Clear Breakpoint 

SIMI <level> Simulate Interrupt 

GO Return to User Context 

IS <count> Instruction Step 


These commands are described in detail in the following sections. 


7.3.2.1 Process Creation Trap (SC) 
SYNTAX: SC <flag> 
This command is used to set or reset a flag which, when set, will 


Cause the message "CREATE TRAP PR=nnnn" to be displayed and the 
target system to be halted whenever a new process is created. "nnnn" 
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is the address of the process record of the. newly created process 
record. 


The command has an optional argument which specifies how the flag is 
to be set: a zero enables the process creation trap and any non-zero 
value disables it. The default value (if no argument is specified) is 
to enable the trap. 


7.3.2.2 Trace Process Scheduling (TP) 
SYNTAX: TP <flag> 


This command is used to set or reset a flag which, when set, will 
cause the message "PRCS TRC PR=nnnn" to be displayed whenever. an 
active process is suspended and a new process becomes active. "nnnn" 
is the address of the process record of the newly activated process. 
This command does not cause the target system to be halted when the 
message is displayed. 


The command has an optional argument which specifies whether or not to 
trace process scheduling: a zero enables the process trace and any 
non-zero value disables it. The default value (if no argument is 
specified) is to enable the trace. 


7.3.2.3 Inspect/Modify/Dump Memory (IM) 


SYNTAX: IM <addr,addr> 


This command is used in two .ways: to display a range of memory 
locations or to interactively display and/or modify memory locations. 
If two arguments are input and the second is greater than the first, a 
memory dump is performed from the first address to the’ second. 
Otherwise, the contents of the first address are displayed and the 
monitor waits for instructions on what to do next. At this point the 
user may assign a new hexadecimal value to the memory location by 
entering the new value terminated by one of the following: 


1) A carriage return to return to the Debugger °"?" 
prompt mode, or 


2) A minus sign to cause the Debugger to back up one 
word and display that value, or 


3) Anything else to display the next word of memory. 
Example: 
?IM 1A,2C <cr> (Dump memory from >001A to >002C) 
001A=0123 4567 89AB CDEF FEDC BA98 7654 3210 


OO2A=0466 2117 | 
?IM 1C <cr> (Inspect/Modify memory starting at >001C) 
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001c=4567 1l10FF <sp> 
QOOlE=89AB - 
001C=10FF <sp> 
OO1lE=89AB <sp> 
0020=CDEF <cr> 


If no argument is specified the command will go into interactive 
mode at location zero. 


7.3.2.4 Inspect/Modify CRU (IC) 


SYNTAX: IC <base,width> 


This command operates in the same manner as the IM command, with 
the difference that the first argument is considered the CRU base 
and the second argument is used as the transfer width. A width of 


zero is considered a width of sixteen. To change either of these 


arguments after the command has been entered it is necessary to 
enter a carriage return and re-enter the command with the new 
arguments. 


Ti Sowews Inspect/Modify Registers (IR) 


SYNTAX: IR 


This command displays the hardware registers WP, PC, and ST for 
the current user routine. The registers are displayed one at a 
time and the user is given the option of changing the register 
value by entering a new value terminated by one of the following: 


2) Inspecting the next register by entering a space, 


3) Inspecting the same register again by entering a minus 
sign, or | 


4) Returning to the Debugger "?" prompt mode by entering a 
Carriage return. 


Example: 
2?IR 
WP=908C 906C <-> 
WP=906C <sp> 


Pc=0480 121A <sp> 
ST=000F 0000 <cr> 


7.3.2.6 Process Record Dump (PD) 
SYNTAX: PD <addr> 














aie e oe 


This command displays an unformatted process record beginning at 
location <addr>. If no address is specified, location zero is assumed. 


The meaning of each field in the process record is explained in 
Appendix A. : 
Example: 
?PD FED6 
FED6=FE36 OFBC FF58 0000 0000 0000 0000 0000 
FEE6=0000 0000 0000 0000 FF58 FBDA FEDO FED6 
FEF6=02E0 FEE2 0380 FEB6 0936 0000 0000 0000 
FFO06=0001 FCOO FF78 0000 0000 0000 0000 0000 
FF16=EBAC EBAC FFAA 0000 FFFF 0001 
7.3.2.7 Displa All Processes (DAP) 


This command displays a listing of all the processes currently in 


SYNTAX: DAP 


system, starting with the active process. The listing displays the 
process record pointer, process identification field of the 
record and current workspace pointer (WP) for each process. The 
low-order byte of the process identification field indicates 
process number of the process in question; the high-order byte 
indicates its creator”s process number. Example: 

?DAP | 

PR=EBAC ID=0102 WP=EBOC 

PR=FB70 IpD=0203 WP=FB7C 

PR=FFAA ID=0000 WP=FFB6 

PR=B4C2 ID=0000 wWP=B462 

PR=FED6 WP=FE76 


Ip=0001 


7.3.2.8 Assign Process Breakpoint (ABP) 


SYNTAX: ABP <addr> 


process record is at 
"PRCS TRAP PR=nnnn" is 
Debugger prompt mode 
"“nnnn" is the process 
command has no 


This command sets a trap on a process’7 whose 
location <addr>, such that the message 
displayed and the target system returns to the 
whenever the process indicated becomes active. 
record address for the newly-activated process. This 
default argument. 


After a trap has been set the Assign Process Breakpoint command prints 
a list of the traps that are currently set. A maximum of four traps 
may be set at any one time. 


7.3.2.9 Delete Process Breakpoint (DBP) 
SYNTAX: DBP <addr> 
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This command removes a trap set by the Assign Process’ Breakpoint 
command for a process whose process record is at location <addr>. 
After the trap has been removed the command prints a list of the traps 
that remain set. If no value is entered, all process traps are 
removed. 


7.3.2.-10 Set Breakpoint (SB) 
SYNTAX: SB <addr> 


This command sets a breakpoint at a given memory location, such that 
the target system will halt, print a "BRK PT PC=nnnn" message and 
return to the Debugger prompt mode when the breakpoint is encountered. 
Only one breakpoint at a time may be resident in the system and is 
removed when encountered. Entering a breakpoint when one is already 
set causes the clearing of the old breakpoint. If no value is entered, 
the current breakpoint is displayed. 


Note that breakpoints may not be set in ROM. 


7.3.2.11 Clear Breakpoint (CB) 
SYNTAX: CB 


This command clears the current breakpoint if one is set. 


7.3.2.12 Simulate Interrupt (SIMI) 
SYNTAX: SIMI <level> 


—_ 


This command is used to simulate an interrupt of <level> to the user’“s 
system. The parameter must be a valid interrupt level in the range 0 
<= level <= 15. If the interrupt is simulated, the new PC and WP are 
displayed. | | 


7.3.2.13 Return To User Context (GO) 

SYNTAX: GO 
This command is used to start or resume execution of the user’s target 
system. The first time GO is entered, execution begins. at the 


beginning of the user“s system; thereafter execution resumes wherever 
it was last suspended (as by a breakpoint or a trap). 


7.3.2.14 Instruction Step (IS) 
SYNTAX: IS <count> 


ia ae 











This command single-steps a target system for a specified number of 
instructions and prints a "WP=nnnn PC=mmmm" message for each 
instruction executed. <count> specifies the number of instructions to 
be single-stepped; the default value (if none is specified) is one. 


Note that Instruction Step will not work if high “memory is ROM. 
FFFC-FFFF must be RAM, and accessible only to the debugger. ~— 
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SECTION 8 


DEBUGGING THE TARGET APPLICATION WITH AMPL 


8.1 GENERAL 


The Advanced Microprocessor Prototyping Laboratory (AMPL) provides 
hardware and software tools enabling the user to perform real-time 
debugging with in-circuit emulation capabilities (execution in the 
target environment monitored by the host development system). Hardware 
requirements for use of AMPL include an FS990/4 or FS990/10 
Minicomputer System with floppy diskette storage and a Model 911 (or 
913) Video Display Terminal (VDT) to provide operator interface. A 
Model 810 printer can be optionally added to provide hard copy 
production capability. 


The FS990 systems include the AMPLUS software system. AMPLUS is an 
operating system containing, an assembler, a text editor, a link 
editor, and a compliment of file manager utilities. 


Additional information on the AMPL system and the FS990 system (and 
peripherals) are available from the local Texas Instruments’7 sales 
office or authorized distributor. 


The purpose of the information that follows is to describe a set of 
predefined AMPL procedures providing a convenient user interface with 
target application systems supported by the Rx. Examples of system 
output will be provided for those routines that require it. Following 
the description of these procedures, a debug session (listing) is 
presented to demonstrate the procedures” actual use. | 


8.2 AMPL PROCEDURES 


A set of AMPL II procedures are supplied the user. For those using 
AMPL I systems, instructions are provided to convert AMPL II 
procedures to AMPL I by removing comments from existing statements. 
These instructions are found in the source code for the AMPL II 


procedures. 


There are three files containing AMPL procs, grouped according to 
these functions: 


1) Basic commands INIT, GO, HALT, IS, SB, CB, SIMI, HELP 
2) Process commands SC, TP, ABP, DBP, DAP, PD | 


3) Miscellaneous commands HP, RP, SM, MM, SP, SF, SH, 
SEMA 





These are broken into three files to accomodate systems with 


limited memory, and normally all three sets of commands are used. 
The first set of commands’ must be read in, and either of the 
other files may also be used. If some other combination of 
Procedures is desired, the user may edit the file containing the 
desired proc or procs and extract them. They may then be read in 
usinng the AMPL COPY command. 


8.3 INSTRUCTION SIMULATION PROCEDURES 


The following procedures simulate specific actions in the target 
system. — | 


8.3.1 Procedure INIT 


PURPOSE: Initialize the debugger with the origins of Rx Routines 
SSSPRC, INTSPC, RELINO and SWITCH. These addresses are needed to 
set hooks in Rx code to implement the “SC*, “TP” and “ABP” 
commands. Init will also initialize the ready queue and the 
suspend HP queue to NIL. 


CALLING SEQUENCE: INIT 


The user will be prompted for’ the origins of the particular 
system routines via the form “INIT’. 


ARG 1 - The origin of routine SSSPRC 
ARG 2 - The origin of routine INITS$PC 
ARG 3 — The origin of routine RELINQ 
ARG 4 - The origin of routine SWITCH 


EXECUTION: The message “INITIALIZATION COMPLETE” is printed after 


all initialization has been performed. 


CONDITIONS: The user should enter zero for any routine not 
in his system. 


AMPL I 
EXAMPLE: ? INIT 


INITIALIZATION COMPLETE 
EXAMPLE: ?INIT 


INITIALIZATION COMPLETE 
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8.3.2 Procedure HELP 


PURPOSE: Display information about the commands available with 
the Rx target debugger. 


CALLING SEQUENCE: HELP © 


CONDITIONS: None. 


EXAMPLE: ? HELP 


KKKEEKKEKKEKEKEEKEKEREEEKEKEKEKEREERE 


* RX TARGET DEBUGGER COMMANDS * 
HKKKKKKKEEKKREKEEKEREKEKREEEKEEEE 


INIT(<load address>) 
‘GO 
HALT 
Is 
SB (<ADDR<,ADDR...->>) 
CB (<ADDR<,ADDR...>>) 
SC (<FLAG>) 
TP (<FLAG>) 
ABP (<PROCESS<, PROCESS. .>>) 
DBP (<PROCESS<, PROCESS. .>>) 
HP(<PROCESS RECD>) 
RP (PROCESS RECD) 
SIMI (LEVEL) 
SM (ADDR<, DISP<, LENGTH> >) 
MM (ADDR, OLD, NEW) 
DAP 
PD(PROCESS RECD) 
SP (PROCESS RECD) 
SF (ROUTINE ADDR) 
SH(HEAP PACKET) 
: SEMA (SEMAPHORE) 


INITIALIZE DEBUGGER | 
START EMULATOR EXECUTION 
HALT EMULATOR EXECUTION 
SINGLE-STEP INSTRUCTION (S) 
SET SOFTWARE BREAKPOINT(S) 
CLEAR SOFTWARE BREAKPOINT (S) 
HALT ON PROCESS CREATIONS 
TRACE PROCESS ACTIVATIONS 
ASSIGN PROCESS TRAP(S) 
DELETE PROCESS TRAP(S) 
HOLD PROCESS 

RELEASE PROCESS 

SIMULATE INTERRUPT 

SHOW MEMORY 

MODIFY MEMORY 

DISPLAY ALL PROCESSES 
DISPLAY PROCESS RECORD 
SHOW PROCESS 

SHOW STACK FRAME 

SHOW HEAP PACKET 

DISPLAY SEMAPHORE 


8.3.3 Procedure SIMI 


PURPOSE: Simulate an interrupt at a particular interrupt level 
in the target system. 


CALLING SEQUENCE: SIMI (level) 
where <level> is the level of the interrupt request. 


EXECUTION: If the interrupt is allowed to occur (determined by 
checking ST), a BLWP is perfomed through the vector stored at the 
appropriate interrupt level. Also, the priority of the CPU is set 
to the level of the interrupt minus one. SIMI returns “INTERRUPT 
IS NOT ALLOWED” if the interrupt was not allowed, and “INTERRUPT 
SUCCESSFUL” if it was. 


CONDITIONS: SIMI may be called whenever the emulator is halted. 
The interrupt is serviced only if the CPU’s' priority is 
numerically less than or equal to the level on which the 
interrupt is raised. . 


EXAMPLE: ? SIMI(0) 
INTERRUPT SUCCESSFUL 


8.4 BREAKPOINT PROCEDURES 

The following procedures implement breakpoints in the target 
software. | 

8.4.1 Procedure SB 

PURPOSE: Set a breakpoint or inspect all current breakpoints. 
CALLING SEQUENCE: 

Set Breakpoints: SB(addr,addr...) where addr is the address at 
which the system sets each breakpoint. (’addr* must be a RAM 
location.) 

Check Breakpoints: SB 

EXECUTION: The message “BREAKPOINT SET AT addr~ is printed for 
each breakpoint set. Up to 16 breakpoints may be set at any one 
time. | 
CONDITIONS: A breakpoint will not be set when the breakpoint 


table is full (the message noted above in "Execution™ will not 
Print). | 




















8.4.2 Procedure CB 

PURPOSE: Clear the given (or all) breakpoints. 

CALLING SEQUENCE: 

Clear The Breakpoints Given: CB(addr,addr...) 

where (addr) is the address of the breakpoint to be cleared. 
Clear All Breakpoints: CB 


EXECUTION: The message “BREAKPOINT CLEARED AT addr” is printed 
for each breakpoint cleared. | 


CONDITIONS: If user supplied address in call contains no 
breakpoint, the message noted above will not print. 


8.4.3 Procedure GO 
PURPOSE: Start Emulator Execution 


CALLING SEQUENCE: GO 


EXECUTION: Target system execution starts from a software 
breakpoint and continues up to the next software breakpoint 
encountered. The instruction at this encountered breakpoint is 
not executed. Software breakpoints are set by the SB (SET 
SOFTWARE BREAKPOINT) command and cleared by the CB’ (CLEAR 
BREAKPOINT) command. 


CONDITIONS: The GO procedure uses an internal procedure called 
*“EBRUN~’ which uses both the emulator and trace modules. Users who 
do not have a trace module may use an alternate version of 
“EBRUN* by editing the procedure file, commenting out the current 
version, and removing comment delimiters from the alternate 
version. 


EXAMPLE: ? GO 


PROCESS CREATED: PR = >9EDA 
? GO 

PROCESS ACTIVE: PR = >9EDA 

PROCESS CREATED: PR = >8BBO 





8.4.4 Procedure SC 


PURPOSE: Enable process creation monitoring by the “GO” 
procedure. 


CALLING SEQUENCE: SC(flag) 


where (flag) ON = "MONITOR PROCESS CREATIONS", and flag OFF = "DO 
NOT MONITOR PROCESS CREATIONS". (Note that the default = ON.) 


EXECUTION: When monitoring is in effect and “GO” is entered, the 
emulator will be halted and message “PROCESS CREATED : PR= >nnnn“ 
will be printed every time a new process is created. 


CONDITIONS: None. 


8.4.5 Procedure TP 

PURPOSE: Enables process activation monitoring by the “GO”. 
CALLING SEQUENCE: TP (flag) | 

where (flag) ON = "MONITOR PROCESS ACTIVATIONS", and flag OFF 


"DO NOT MONITOR PROCESS ACTIVATIONS". (Note that the default 
ON.) 


EXECUTION: When monitoring is in effect and “GO” is entered, the 
emulator will be halted and the message “PROCESS ACTIVE: PR= 
>nnnn~ will be printed every time a new process is created. 


CONDITIONS: None. 


8.5 REALTIME EXECUTIVE PROCEDURES 7 

The following AMPL procedures use constructs of the 
Microprocessor Executive. 

8.5.1 Procedure HP 

PURPOSE: Hold an RX process. 

CALLING SEQUENCE: HP(addr) 

where (addr) is the address of the process record of the process 
to be held. (Entering “HP® by itself will print a list of all the 
currently held processes.) 

EXECUTION: The process is removed from the ready queue or 


semaphore queue in a suspend queue that exists outside of the Rx 
system. , 














CONDITIONS: The process may not execute until it is released via 
the RP procedure. A process may not be held when the processor is 
halted at a process creation breakpoint; ABP or SB may be used to 
halt the processor at a later point to perform the HP operation. 


8.5.2 Procedure RP 

PURPOSE: Release a process held by HP. 

CALLING SEQUENCE: RP(process) 

where (process) is the process to be released. 


EXECUTION: A process that has been held by HP is’ released from 
the suspend queue and either scheduled for execution or 
resuspended upon a semaphore that it. was suspended upon when 
held. | | 


CONDITIONS: A process may not be released when the processor is 
halted at a process creation breakpoint; ABP or SB may be used to 
halt the processor at a later point to perform the RP operation. 


8.5.3 Procedure ABP 
PURPOSE: Assign process traps. 
CALLING SEQUENCE: ABP (addr) 


where (addr) is the address of the process record of the process 
to be "trapped". 


EXECUTION: A breakpoint is set on a given process so that the 
system is halted at the next instance in which the process 
becomes active. The message “PROCESS TRAPPED: PR= >nnnn* will be 
Printed when this occurs. 


CONDITIONS: If no argument is supplied, a list of all process 
traps currently set is printed. A maximum of four process traps 
may be set at any one time. | | 


EXAMPLE: ? ABP 
LIST OF ALL TRAPS CURRENTLY SET 
PROCESS >9EDA 
PROCESS >8BBO 





8.5.4 Procedure DBP 





PURPOSE: Delete process traps. 
CALLING SEQUENCE: DBP (addr) 


where (addr) is the address of a process record of a process’ for 
which a trap is to be removed. 


EXECUTION: 
CONDITIONS: If no argument is supplied, all currently set traps 


will be removed. Up to four traps may be removed at one time. 


8.5.5 Procedure PD 


PURPOSE: Print a formatted dump of an Rx process record. 


CALLING SEQUENCE: PD(addr) 

where (addr) is the address of the process’ record to be 
displayed. 

EXECUTION: The procedure prints out a formatted listing of an Rx 


process record given its address. 


CONDITIONS: None. 














EXAMPLE: 
2?Pp (05960) 

DUMP OF PROCESS RECORD AT >5060 

NEXTWS = >590C LEX$8 = >0000 PC = >0C7A FIRST = >0000 
CALL = >0268 LEX$9 = >0000 ST = >p00d0 NS/OBJ = »>0000 
UNUSED = >0000 GLOBAL = >595C OUTPUT = »>0000 OBJECT = >0000 
LEX$l1 = >595C  STKMIN = >517C INPUT = »>0000 PRLIST = >5CFC 
LEX$2 = >0000 STKMAX = >592C PRITY = >OO1E LSTRTD = >Q000 
LEXS3 = >0000 UNUSED = >0000 CLKSRV = >0000 QNEXT = >0000 
LEX$4 = >0000 LWPI = >02E0 MPXPTR = >5FFO QUEUE = >0000 
LEX$5 = >0000 CNTEXT = >596C CL/RS = »>0000 INTLVL = »>0000 
LEXS6 = >0000 RTWP = >0380 XHNDLR = >0000 CR/MY = >0304 
LEXS7 = >0000 WP = >5FCE 








8.5.6 Procedure SEMA 
PURPOSE: Display information about a semaphore. 
CALLING SEQUENCE: SEMA(addr) 


where (addr)is the address of the semaphore. 
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EXECUTION: This procedure prints out a listing of a semaphore 
value given a semaphore address. 


CONDITIONS: None. 


8.5.7 Procedure SM 

PURPOSE: Show memory. 

CALLING SEQUENCE: SM(addr,<length>,<displacement>) 

where (addr) is the address to start, <length> is the length to 
display (default=2), and <displacement> is the displacement to 
display (default=0) 


EXECUTION: Shows the contents of one or more absolute memory 
locations. 


CONDITIONS: None. 


EXAMPLE: ? SM(>8BBO0,>4C) 


>8BBO (>0000) >8B10 >0676 >9F5C >9BD2 (ea. SV ef «aR 2) 

>8BB8 (>0008) >0000 >0000 >0000 >0000 (oe de ea Se 3 

SAME AS LAST LINE | 7 
>8BC8 (>0018) >9BD2 >878C >8BBO >8BBO Use 2s” 30: 40 
>8BD0 (>0020) >02E0 >8BBC >0380 >8B90 (oe. Ge wee cece. 
> BD8 (>0028) >0284 >000F >0000 >0000 Gok. cee. G26. are 
>8BEO (>0030) >001E >FCOF >9F7C >0000 (0 fe of ec 
>8BE8 (>0038) >0000 >0000 +0000 >0000 Coe. Ge tie exe 
>8BFO (>0040) >9B74 >9B74 >9FAE >0000 (es. ots 24 «s 

Ces ; 


>BBFB (>0048) >0102 >0102 


8.5.8 Procedure MM 
PURPOSE: Modify memory. 
CALLING SEQUENCE: MM(addr,old,new) 


where (addr) is the address to modify, (old) is the verification 
value, and (new) is the new value. 


EXECUTION: Modifies the contents of any single (word) location in 
memory. Note that caution should be exercised when using this 
command. 


CONDITIONS: None. 


a te tee 





8.5.9 Single Step Instruction(s) (IS) 


PURPOSE: Instruct the emulator to execute a specified number 
instruction and then halt. 


CALLING SEQUENCE: IS(count) 


where (count) specifies the number of instructions to be 
individually stepped through. When no argument is’ supplied, 
default is one. | 


EXECUTION: One or more instructions are executed in single-step 
mode, printing information about each instruction before it is 
executed. “IS” prints the current instruction, the current WP, PC 
and ST, and the source and destination operands (if any), 
executes the current instruction and then displays the above 
information about the next INSTRUCTION TO BE EXECUTED. 


CONDITIONS: The emulator comparison logic may not be utilized 
during use of the IS procedure. However, IS can be used with with 
the emulator trace logic and the trace module when only the 
instruction need be recorded. 3 


8.5.10 Procedure SP 
PURPOSE: Show process. 
CALLING SEQUENCE: SP(process) 


where (process) is the address of the process record. 


EXECUTION: Displays information about stack and heap usage, 
process ID, exceptions outstanding, etc. 


é 


CONDITIONS: None. 


EXAMPLE: ? SP(>8BBO) 
? SP(>8BBO0) 
SHOW PROCESS >8BBO 


STACK BASE = >878C STACK LIMIT = >8BBO STACK BOUNDARY = >8BBO0 
STACK SIZE = >083F STACK USED (MAX) = >087F STACK USED (CUR) = >/FAF 
PRIORITY = 30 


NO OUTSTANDING EXCEPTIONS 
NEXT PROCESS IN LIST = >9B74 NEXT PROCESS IN QUEUE = >9FAE 
CREATOR’S ID = >0l MY ID = >02 








8.5.11 Procedure SF 

PURPOSE: Show stack frame. 

CALLING SEQUENCE: SF(<addr>,<displacement>,<length>) 

where (addr) is the address of the routine or process’ code 
(default=current routine), <displacement> is the displacement 


into the frame (default=0), <length> is the length to display 
(default=rest of frame). 


EXECUTION: Displays the specified memory locations. The message 
“STACK FRAME NOT FOUND” is printed if the requested routine or 
process is not in the system at the time SF is entered. 


CONDITIONS: None. 


8.5.12 Procedure SH 
PURPOSE: Show heap packet. 
CALLING SEQUENCE: SH(addr,<displacement>,<length>) 


where <addr> is the address of the heap packet, <displacement> is 


the displacement into the packet (default=0), and <length> is the 


length to display (default=rest of packet). 


CONDITIONS: None. 


8.5.13 Procedure HALT 
PURPOSE: Halt emulator (and trace module) execution. 
CALLING SEQUENCE: HALT 


EXECUTION: HALT will reset the default process to the currently 
active process. 


CONDITIONS: None. 


8.6 AMPL WALK-THROUGH DEBUGGING SESSION 


The listing that follows demonstrates a debugging session with 
AMPL utilizing “RXDEMO” as the program being debugged. Note that 
Appendix E supplies the user an assembler listing and link map of 
“RXDEMO” for use with this session. 


8.6.1 Getting Ready 


ed 


ay i? ae CP (beter davis. 
i =. Wboce ‘ a en th 


nv 


J 


2 


Before proceeding with the debug session, 


AMPL II - procedures 


access to the AMPL emulator in future debug 


should be built. This 


set of compiled procedures can be use 
therefore time spent will pay dividends in the future. To build 
this set of procedures, load AMPL and proceed as shown below: 


? CLR(50) 
? COPY (*<pathname 


? COPY (*<pathname 


J 


COPY (*“<pathname 


J 


COPY (*<pathname 


J 


SAVE (“<pathname 


J 


EXIT 


of RXAMPLA‘ ) os 
of RXAMPLB“ ) aie 
of RXAMPLC”) oa 
of user proc>”~) ie 


of saved procs>”) ce 


a set of "compiled" 
will provide for fast 
sessions. The same 

qd on all Rx systems, 


Load and "compile”™ the 
procedures which are 
provided with Rx 

Repeat with any user procs 
"SAVE" the compiled procs 


Finished with this phase 


CAUTION 
DO NOT remove this disk during the debug session as the second 
generation of AMPL uses overlays on the disk which contains’ the 
debug session. At the beginning of a session, always reload AMPL 
to ensure the initial state of this disk is recorded by AMPL. For 
every other debug session, restore the procedures to the system. 


Note that when attempting “COPY”, the user must first perform a 
CLR command with an operand of 50 to ensure that a symbol table 
of the appropriate size is created. 
8.6.2 The Debug Session 
The debug session begins as any other, with loading of the AMPL 
Program (NOTE:comments are bracketed by asterisks, and are not to 
be typed in): 

*** OBTAIN A HARD COPY (if desired) *** 
LIST(“LP*) 

*** RESTORE THE SAVED PROCEDURES *** 
RSTR(*<path name of saved Rx procs>”~) 

*** INITIALIZE THE BUFFER AND TRACE MODULES *** 


EINT(“EMO1*,0,°TM0O1*) .. O ==> target clock 
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-. lL ==> host clock 7 
*** LOAD THE DEMONSTRATION PROGRAM *** 
? LOAD(*<path name of demo load module>’”,0) 
*** GET A LISTING OF THE SYMBOLS DEFINED *** 
? MSYM 


LOAD MODULE SYMBOLS: 
LOAD POINT: >0000, LENGTH: >150E BYTES. 


i Re St ee perme oe em: 


- RXDEMO PGMID >0000 RXKERN IDT >0000 CONFIG IDT >08pD8 
SBOOTP LCL >08E4 SDEFAU LCL >O08DE SFILL LCL >08E0 
SIODIR LCL >O8FO SLREX LCL >O8DA SRAMTB LCL >O8EE 
SRESTA LCL »>08D8 SSTKSZ LCL >O08E2 SSYSCR LCL >08pC 
IODIR LCL >0O8F8 RAMTB LCL >O08F2 RXDEMO IDT #£>O8FA 
EPILOG LCL >092¢c FRMSIZ LCL >0902 HPSIZE LCL >090A 
LEXLVL LCL »>0904 PRIORI LCL »>0906 PROLOG LCL >090C 
RXDEMO LCL >O8FA STKSIZ LCL >0908 SySTmM$ LCL >O8FA 
PRODUC IDT >0938 EPILOG LCL >OAF6 FRMSIZ LCL >0940 
HPSIZE LCL >0948 LEXLVL LCL >0942 PRIORI LCL >0944 
PRODUC LCL >0938 PROLOG LCL >09DC SENDLP LCL >0A42 
STKSIZ LCL >0946 CONSUM IDT >0B02 CONSUM LCL >0B02 
EPILOG LCL »>OBE6 FRMSIZ LCL >OBOA HPSIZE LCL >0B12 
LEXLVL LCL >0B0C PRIORI LCL >OBOE PROLOG LCL >0B48 
STKSIZ LCL >0B10 WAITLP LCL >0B70 WAITIO IDT >OBF2 
BAUDLP LCL >0c40 BAUDTB LCL >0c50 CHARLP LCL >0p24 
CONTRL LCL >0C4E CR LCL >0CE7 FOUND LCL >0CC2 
LOADLP LCL >0C36 MATCH LCL >0c48 MSGENT LCL >0D20 
MSGEXI LCL >0D3C NULLCH LCL >O0CE6 PAD | LCL >O0CD2 
PADCR LCL >0cDO SENDOF LCL >O0CE2 TABLE LCL >O0CE8 
TBLLP LCL >OCB8 TESTSP LCL >0c10 TISCIN LCL >0c70 
TISCOT LCL >0C92 TISMSG LCL >0p18 TISSET LCL >OBF2 
TIMELP LCL >0C26 WAITLP LCL >0c84 WTLPS1 LCL >OCAE 
WTLP$2 LCL >OCD6 ESPRCS IDT >0p40 GHOSTS IDT >OEA4 
CSACKN IDT >OEDC CSALLO IDT >OFOE CSINIT IDT >OFAA 
CSRECE IDT >1094 CSSEND IDT >1102 CSTERM IDT >1182 
CSWAIT IDT >1212 CSSMSG IDT >1244 CSSHEA IDT >125E 
CLKSTE IDT >1278 CKSEMA IDT >1314 DSINIT IDT >132¢c 
DSTERM IDT >1330 EXITS1 IpDT >1334 FSTERM IDT >1354 
HPSSYS IDT >1358 INITSE IDT £>1364 MSGSIN IDT #£>13AC 
MYSMPX IDT >13B8 RTSENT IDT >13c2 RTSEXI IDT >13p0 
SETMAS IDT >13D8 TERMSE IpDT ‘>13F4 CKSSEM IDT #£>142E 
EXCEPT IDT >1442 EXITSO IDT >1460 HPSFRE IDT >l46E 
HPSNEW IDT >14B2 | 

100 ENTRIES IN TABLE. 


**k GET A LIST OF COMMANDS AVAILABLE *** 


? HELP 


RKEKKKKKRKKKKKKRKEKKRKEKRKEKKERERRRRKKKEESK 


* RX TARGET DEBUGGER COMMANDS * 
HRRKKKKKEKKEREERREREKEEERRAKEEEES 


INIT< (LOAD ADDR) > 

GO 

HALT 

IS< (COUNT) > 

SB (<ADDR<,ADDR...>>) 

CB (<ADDR<, ADDR. ..>>) 

SC (<FLAG>) 

TP (<FLAG>) 

ABP (<PROCESS<, PROCESS. .>>) 
DBP (<PROCESS<, PROCESS. .>>) 
HP(<PROCESS RECD>) 
RP(PROCESS RECD) ~ 

SIMI (LEVEL) 

SM (ADDR<, DISP<, LENGTH>>) 
MM (ADDR, OLD, NEW) 

DAP 

PD(PROCESS RECD) 
SP(PROCESS RECD) 
SF(ROUTINE ADDR) 
SH(HEAP PACKET) 

SEMA ( SEMAPHORE) 


INITIALIZE DEBUGGER 

START EMULATOR EXECUTION 
HALT EMULATOR EXECUTION 
SINGLE-STEP INSTRUCTION(S) 
SET SOFTWARE BREAKPOINT(S) 
CLEAR SOFTWARE BREAKPOINT(S) 
HALT ON PROCESS CREATIONS 
TRACE PROCESS ACTIVATIONS 
ASSIGN PROCESS TRAP(S) 
DELETE PROCESS TRAP(S) 
HOLD PROCESS 

RELEASE PROCESS 

SIMULATE INTERRUPT 

SHOW MEMORY | 
MODIFY MEMORY 

DISPLAY ALL PROCESSES 
DISPLAY PROCESS RECORD 
SHOW PROCESS 

SHOW STACK FRAME 

SHOW HEAP PACKET 

DISPLAY SEMAPHORE 


# 


*** INITIALIZE THE RX PROCS *** 


? INIT 
INITIALIZATION COMPLETE 


*** SIMULATE A LEVEL ZERO INTERRUPT *** 
alla TO RESET THE SYSTEM ahaa 


? SIMI(0) 
INTERRUPT SUCCESSFUL 


*** TRACE PROCESS ACTIVIATION *** 


*** HALT ON PROCESS CREATION ***- 

















? GO 
PROCESS 
PROCESS 
PROCESS 
PROCESS 


2? GO 
PROCESS 
PROCESS 
PROCESS 
PROCESS 


? GO 
PROCESS 
PROCESS 
PROCESS 
PROCESS 
PROCESS 
PROCESS 
PROCESS 
PROCESS 


? GO 
PROCESS 
PROCESS 
PROCESS 
PROCESS 


2? GO 
PROCESS 
PROCESS 
PROCESS 
PROCESS 
PROCESS 


PROCESS 
PROCESS 


~ -. PROCESS 


PROCESS 
PROCESS 


*** START EMULATION *** 


ACTIVE: PR = >9F72 
ACTIVE: PR = >9F72 
ACTIVE: PR = >9F72 
CREATED: PR = >9CEO0 


*** GHOSTS PROCESS STARTED *** 


ACTIVE: PR = >9F72 
ACTIVE: PR = >9F72 
ACTIVE: PR = >9F72 
CREATED: PR = >9C5E 


*** SYSTEM PROCESS STARTED *** 


ACTIVE: PR = >9F72 
ACTIVE: PR = >9F72 
ACTIVE: PR = >9F72 
ACTIVE: PR = >9F72 
ACTIVE: PR = >9C5E 
ACTIVE: PR = >9C5E 
ACTIVE: PR = >9C5E 
CREATED: PR = >99FC 


*** PRODUCER PROCESS STARTED *** 


ACTIVE: PR = >9C5E 
ACTIVE: PR = >9C5SE 
ACTIVE: PR = >9C5SE 
CREATED: PR = >9794 


*** CONSUMER PROCESS STARTED *** 


ACTIVE: PR = >9C5E 
ACTIVE: PR = >9C5E 
ACTIVE: PR = >9C5E 
ACTIVE: PR = >9C5E 
ACTIVE: PR = >99FC 


*** TYPE A CARRIAGE RETURN ON THE TARGET SYSTEM adie 
**k* TO AUTO-BAUD THE TERMINAL, THEN TYPE ANY LETTER *** 
ee TO BE INPUT TO THE PRODUCER PROCESS. ct 


ACTIVE: PR = >99FC 
ACTIVE: PR = >99FC 
ACTIVE: PR = >99FC 
ACTIVE: PR = >99FC 
ACTIVE: PR = >99FC 





PROCESS ACTIVE: PR = >9794 
PROCESS ACTIVE: PR = >9794 
PROCESS ACTIVE: PR = >9794 
PROCESS ACTIVE: PR = >9794 
PROCESS ACTIVE: PR = >99FC 


*#** HIT <CMD> ON THE HOST SYSTEM *** 
aha TO ENTER COMMAND MODE ae 


2? HALT 
*** TURN OFF PROCESS TRACING *** 


? TP (OFF) 


J 


SC (OFF). 


*** DISPLAY ALL PROCESSES IN SYSTEM *** 


? DAP 
STATUS SUMMARY OF ALL EXISTING PROCESSES 
| | LEXICAL CURRENT 
PROCESS NUMBER ADDRESS LEVEL STATUS PRIORITY 
4 >99FC 1 ACTIVE 256 
2 >9CEO 1 READY 32767 
5 >9794 1 WAITING | 256 
*** >99FC IS THE PROCESS RECORD ADDRESS FOR THE PRODUCER pitas 
*** >99E0 IS THE PROCESS RECORD ADDRESS FOR THE IDLE PROCESS *** 
*#** >9974 IS THE PROCESS RECORD ADDRESS FOR THE CONSUMER aiid 


*kxk DISPLAY THE REGISTERS FOR THE CURRENT ROUTINE *** 


? DR 

RO = >0000 R8 = >0C70 PC = >0C86 / >16FE JNE WAITIO.WAITLP 
Rl = >9560 ROY = >97E6 WP = >99A2 

R2 = >0000 RIO = >97E2 ST = >900F 

R3 = >5400 R11 = >0000 

R4 = >0000 R12 = >0080 

RS = >0000 R13 = >99C2 

R6 = >0000 R14 = >0A52 

R7 = >99FC R15 = >800F 


#** SET A BREAKPOINT IN PRODUC AFTER CALL TO TISCIN *** 
2 SB(PRODUC.+>11A) 
BREAKPOINT SET AT PRODUC.+>011A / >CEA9 MOV @RXDEMO.+>0002(R9) ,*R1LO+ 
**k* RESTART EMULATION *** | | 


? GO 


i ; 
K 
Ne. , 
~. 











*** NOW TYPE “K” ON THE TARGET TERMINAL *** 


BREAKPOINT ENCOUNTERED AT ADDRESS: PRODUC.+>0l1llA / >CEAQ 
9) ,*R10+ 


*** DISPLAY THE LOCAL FRAME OF THIS PROCEDURE *** 
*** THIS WILL NOT WORK FOR ROUTINES WITH AN *** 


ae OPTIMIZED LINKAGE Se 
? SF 
STACK FRAME FOR ROUTINE PRODUC. 
>99F4 (>0000) >0068 >956E >9560 (ch, «fk 


WORKSPACE REGISTERS ARE: 





MOV @RXDEMO. +>00( 


>0A52 / >CEA9 MOV @RXDEMO.+>0002(R9) ,*RI10: 


RO = >0000 RB = >0938 PC = 

Rl = >9560 ROY = >99F4 wre = >99C2 

R2 = >9560 RIO = >97E2 ST = >800F 

R3 = >0000 R11 = >0A52 

R4 = >0000 R12 = $0000 

R5 = >0000 R13 = >9C2A 

R6 = >0000 R14 = >0928 

R7 = >99FC R15 = >OOOF 
**k DISPLAY THE MESSAGE BUFFER Rl POINTS *** 
KK TO FOUR BYTES OF INFORMATION. KKK 

~~ >9560 (>0000) >004B »>0068 (4K. he 
**xk BR MESSAGE BUFFER IS PART OF A HEAP PACKET kx 
**k* MSGBUF-4 POINTS TO THE START OF THE PACKET *** 
*** SH (SHOW HEAP) WILL DISPLAY THE WHOLE PACKET *** 
? SH(R1-4) 
HEAP PACKET AT ADDRESS: >955C SIZE: >OOOA 


>955c (>0000) >9554 >0000 >004B »>0068 (.T .«.- 6K 
>9564 (>0008) >0009 (.. 

**x* THE FIRST WORK OF A MESSAGE PACKET IS A *** 
**x* SEMAPHORE USED TO ASSURE EXCLUSIVE ACCESS *** 
ali THERE ARE NO WAITERS ON IT BEFORE A bail 
a! MESSAGE HAS BEEN SENT TO THE CONSUMER Cae 


? SEMA(>9554) 
SEMAPHORE VALUE IS >9554 
THERE ARE NO WAITERS OR UNRECEIVED SIGNALS PRESENT 
THIS SEMAPHORE IS NOT ASSOCIATED WITH ANY INTERRUPTS 


De a Ce Oe Oe a ae Oe ses eet ay bs 2 Sg a 


kkk TS(N) WILL SINGLE STEP EXECUTION “N° STEPS *** 


? IS 


MOV @RXDEMO.+>0002(R9) ,*R1LO+ 


WP=>99C2 
WP=>99Cc2 
MOV R1,*R1O+ 
? Is 


MOV R1,*R1LO+ 
WP=>99C2 
WP=>99C2 

BLWP *R/ 


kk 
kak 
kkk 


kkk INS 


? SB(PC+4) 


BREAKPOINT’ SET AT PRODUC.+>0124 


2? GO | 


BREAKPOINT ENCOUNTERED AT ADDRESS: PRODUC.+>0124 


8) ,*R10+ 


Pc=>0A52 
Pc=>0A56 


PC=>0A56 
PC=>0A58 


TEAD, 


ST=>800F 


ST=>800F 


ST=>800F 
ST=>800F 


SRC=>99F6 
SRC=>99F6 


SRC=>99cC4 
SRC=>99C4 


/ 
/ 


>956E 
>956E 


>9560 
>9560 


BUT IT WILL TAKE A LONG TIME 


*** STEP FIVE MORE INSTRUCTIONS *** 


ST=>200F 
StT=>COOF 


- §T=>CO0OF 


ST=>COO0OF 


ST=>COOF 
ST=>COOF 


ST=>COOF 
ST=>COOF 


ST=>COO0OF 
ST=>COOF 


? Is(5) 

MOV @RXDEMO.+>0016(R8) ,*R1O+ 
WP=>99C2 PC=>0A5C 
WP=>99C2 Pc=>0A60 

MOV @RXDEMO. (R9) ,*R1LO+ 
WP=>99C2 PC=>0A60 
WP=>99C2 Pc=>0A64 

MOV R8,R2 
WP=>99C2 Pc=>0A64 
WP=>99C2 PC=>0A66 

AI R2, RXDEMO.+>003D 
WP=>99C2 PC=>0A66 
WP=>99C2 PC=>0A6A 

MOV R2,*R1LO+ 
WP=>99C2 PC=>0A6A 
WP=>99C2 PC=>0A6C 

BLWP *R7 | 


SRC=>094E 
SRC=>094E 


SRC=>99F4 
SRC=>99F4 


SRC=>99D2 
SRC=>99p2 


SRC=>99C6 
SRC=>99C6 


SRC=>99C6 
SRC=>99C6 


AB. NON SON OO OARS 


SET A BREAKPOINT AFTER THE CALL *** 


/ >CEA8 MOV @RXDEMO.+>0016— 


>0080 
>0080 


>0068 
>0068 


>0938 
>0938 


>0938 
>0975 


>0975 
>0975 


DST=>97E2 


DST=>97E2 


DST=>97E4 
DST=>97E4 


DON’T SINGLE STEP THROUGH A SUBROUTINE CALL *** 
IT WILL WORK, 
TO GET BACK TO THE PRODUC PROCESS 


kkk 
kkk 


DST=>97E2 
DST=>97E2 


DST=>97E4 
DST=>97E4 


DST=>99C6 
DST=>99C6 


DST=>97E6 
DST=>97E6 


/ >CEA8 MOV @RXDEMO.+>0016(R8) ,*RIO+ 


a 


>0080 
>956E 


>9560 
>9560 


>956E 
>0080 


>9560 
>0068 


>9560 
>0938 


>9566 
>0975 

















*** THE ARGUMENTS HAVE BEEN PUSHED, DISPLAY *** 
mae THE TOP THREE ITEMS ON THE STACK ae 


? SM(R10-6,6) 
>97E2 (>0000) >0080 >0068 >0975 (.. eh .u ) 


*** = =6>0975 IS A POINTER TO A STRING IN ROM, ee 
*** DISPLAY THE STRING WHICH IS 15 CHARACTERS *** 


2? SM(>0975,15) 
>0974 (>0000) >0050 >524F »>4455 »>4345 (.P RO DU CE ) 
>097cC (>0008) >5220 >5345 >4E44 >5320 (R SE ND §5 ) 
*** SET ANOTHER BREAKPOINT AFTER THE NEXT CALL *** 
? SB(PC+4) 


3REAKPOINT SET AT PRODUC.+>0138 / >CEA8 MOV @RXDEMO.+>0016(R8) ,*R10+ 
? GO 


*** THE TARGET TERMINAL JUST PRINTED “PRODUCER SENDS ~ *** 


BREAKPOINT ENCOUNTERED AT ADDRESS: PRODUC.+>0138 / >CEA8 MOV @RXDEMO.+>001€ 


8) ,*R10+ 
*** NOW GET RID OF ALL BREAKPOINTS *** 


"aye ? CB 
CLEARING ALL BREAKPOINTS 


***x SHOW THE CONSUMER PROCESS *** 


? SP(>9794) 
SHOW PROCESS >9794 
STACK BASE = >957C STACK LIMIT = >975C 
STACK SIZE = >01C0 STACK USED (CUR) = >0004 
PRIORITY = 256 


NO OUTSTANDING EXCEPTIONS | 
NEXT PROCESS IN LIST = >99FC NEXT PROCESS IN QUEUE = >9CEO 
CREATOR’S ID = >03 MY ID = >05 


**x* DUMP THE CONSUMER PROCESS RECORD *** | ne. 


? PD (>9794) 
DUMP OF PROCESS RECORD AT >9794 


NEXTWS = >971C LEX$S8 = >0000 PC = >0B60 FIRST = >0000 
CALL = >028E LEX$9 = >0Q000 ST = >000F NS/OBJ = >0100 
UNUSED = >0000 GLOBAL = >978E OUTPUT = >0000 OBJECT = >0000 
LEX$1 = >978E STKMIN = >957C INPUT = >0000 PRLIST = >99FC 
LEX$S2 = >0000 STKMAX = >975C PRITY = >0100 LSTRTD = >0000 
LEX$S3 = >0000 UNUSED = >0000 CLKSRV = >0000 QONEXT = >9CEO - 
LEXS4 = >0000 LWP I = >02E0 MPXPTR = >9FE6 QUEUE = >9566 
LEX$5 = >0000 CNTEXT = >971C CL/RS = >0000 INTLVL = >FFFF 
LEX$6 = >0000 RTWP = >0380 #$XHNDLR = >0000 cCR/MY = >0305 
LEX$7 = >0000 wp = >975C 


*** SET A PROCESS BREAKPOINT ON THE CONSUMER *** 
? ABP(>9794) 


2? GO 
PROCESS TRAPPED: PR = >9794 


wa SET A BREAKPOINT AFTER THE CALL TO CSRECEIVE *** 
? SB(CONSUM. +>7E) 
BREAKPOINT SET AT CONSUM.+>007E / >C069 MOV @RXDEMO.+>0002(R9),RI1 
pREAKPOIN’ ENCOUNTERED AT ADDRESS: CONSUM.+>007E / >C069 MOV @RXDEMO.+>0002 


*** SHOW THE FRAME TO FIND THE ADDRESS OF THE MESSAGE *** 


? SF 
STACK FRAME FOR ROUTINE CONSUM. | 
>978E (>0000) >956R >9560 (on. << ) 


WORKSPACE REGISTERS ARE: 


RO = >0000 RS = >0B02 pc = >0B80 / >c069 MOV @RXDEMO.+>0002(R9) ,R1 
RL = >9560 ROY = >978E WP = >975C 

R2 = >9790 RIO = >957c ST = >800F 

R3 = >0000 R11 = >0B80 

R4 = >0000 R12 = >0000 

R5 = >0000 R13 = >9C2A 

R6 = >0000 R14 = >092C 

R7 = >9794 R15 = >300F 








*** DUMP THE MESSAGE PACKET; REMEMBER THE PACKET *** 
nee STARTS 4 BYTES BEFORE THE MESSAGE BUFFER oe 


? SH(R1-4) 
HEAP PACKET AT ADDRESS: >955C SIZE: >000A 
>955C (>0000) >9554, >0000 >004B >0068 (67 as «K sh) 
>9564 (>0008) >0009 (.. ) 


*** INDEED, THE CHARACTER IN THE *** 
*** MESSAGE IS >4B, OR *K* ka 


*** SHOW THE ACCESS SEMAPHORE FOR THE MESSAGE *** 


? SEMA(>9554) 
SEMAPHORE VALUE IS >9554 
THERE ARE 1 WAITERS PRESENT 
THIS SEMAPHORE IS NOT ASSOCIATED WITH ANY INTERRUPTS 


*** THE CONSUMER HAS ALLOCATED THE MESSAGE BUFFER, *** 
*** SO THE PRODUCER HAS TO WAIT UNTIL THE CONSUMER *** 
*** IS FINISHED BEFORE IT CAN SEND THE NEXT MESSAGE *** 


*** NOW, LET THE PROGRAM RUN UNTIL IT FINISHES *** 


? CB 
CLEARING ALL BREAKPOINTS 


J 


TP (OFF) 


na) 


SC (OFF) 

2 GO 

*** TYPE CHARACTERS ON THE TARGET TERMINAL UNTIL *** 
***x YOU ARE SATISFIED THAT THEY ARE SENT TO THE ***- 
ee CONSUMER PROCESS, THEN TYPE A “Z”. ae 


*** HIT <CMD> ON THE HOST *** 


J 


HALT 


**x* SHOW THE PROCESSES LEFT IN THE SYSTEM *** 


2? DAP 
STATUS SUMMARY OF ALL EXISTING PROCESSES 


| LEXICAL CURRENT 
PROCESS NUMBER ADDRESS LEVEL STATUS PRIORITY 
2 >9CE0O 1 ACTIVE 32767 


*** ONLY THE IDLE PROCESS IS LEFT *** 


? EXIT 


¢ 


After the program is started, type a Carriage return, and then 


type characters to be input to the PRODUCer process. To terminate 
the program, type a capital °’27. 











APPENDIX A 


RX DATA STRUCTURES 


A.l1 GENERAL 


This appendix describes the data structures used by Rx. The user 
initialized data structures are discussed first, such as the RAM 
configuration table, the segment table, and the trap table. The 
following subsections cover the Process record, global data 
structures, and process local data structures. The data structures 
used by the processor are discussed, such as the processors registers 
and local variables, and stack areas. 


Note that some records support the File I/O Decoder and I/O Subsystems 
specifically, while some contain fields pertaining to the File I/0 
package. For more information reference the Device Independent File 
I/O Package User”~s Manual, MP386. 


A.2 USER INITIALIZED DATA STRUCTURES 

The data structures described must be initialized by the user and 
defined in the "CONFIG" module. Further information on this 
configuration module can be found in Section VI. 

A.2.1 RAM Configuration Table 


This table describes the configuration of RAM memory used as data 
space by Rx. It is included anywhere in the user”s code space (ROM). 


NOTE: This table MAY require descending addresses, and DOES require 
non-overlapping addresses. 


, length | Length of contiguous RAM (16-bit logical 
: ! value in number of bytes) 

#02 +-----+------- : 
start address | Address at which contiguous RAM starts 
— 
) * | Length and start are repeated for each 
| contiguous RAM area. 
ae 
| length=0 End of table is indicated by a length of 
| ZerO. : | 





A.2.2 I/O Subsystem Directory 


A table is included in the "CONFIG" module which lists pointers to 
service directory port constants defining an I/O subsystem. The last 
word in this directory is set to Zero to terminate the list. This 
structure is subsystem dependent, and unless the "CONFIG" module is 
modified by the user, the default value is assumed. This default 
directory is empty and does not support an I/O subsystem. 


IOSVCDIR@ ( #1) Pointer to I/O service directory #1 
PORTCONSG (#1) Pointer to port constants list #l 
IOSVEDI RG ( #2) Pointer to I/O service directory #2 
PORTCONSG (#2) Pointer to port constants list #2 
Pace ee 

¥ 

* 

0 


A.3 RX DATA STRUCTURES 


The data structures described are used by Rx to manage processes, and 
the memory area associated with a process. The process record is the 
fundamential data structure used by Rx. From it one can get to all 
other data structures used by Rx. All data structures (except the 
Process record shown here) are in alphabetical order. 


A.3.l1 Process Record 


The process record is the fundamental structure which is used by Rx to 
access all other data structures. A unique process record exists for 
each instance of a process. Register 7 will always point to the 
process record of the currently active process. The layout of the 
process record is shown below: 


100:  sasaeeeeeo oa 
next wp Next workspace pointer to be used 
#02 


call handler | Entry point of call handler 











#06 


#16 


#18 


#1C 
#1E 
#20 
#22 
#24 
#26 
#28 
#20 
#2C 
#2E 


#30 


#32 


level 0 
7 
} 

* 

| , 

* 

; level 9 

| 

: global base 
eee een a 


es ee ee 


clock 
service 


Display level 0 frame pointer 
Intermediate level frame pointers 


Display level 9 frame pointer 
Stack frame of process 
Minimum stack address for process 


Maximum stack address for process 


Not used 

LWPI instruction (used in starting process) 
Machine context of the process 

(workspace pointer) 


RTWP Instruction 


The following are valid only if pointed to 
by the context field above. 

The workspace pointer of the machine context 
The program counter of the machine context 
The status word of the machine context 
Pointer to file descriptor for “output” 
Pointer to file descriptor for “input” 


Priority of the process 


Pointer to the clock service record 





mpxptr Address of executive record led 
#36— 2232+ --------- 
error | Error class code 
Class code 
a 
reason code Error reason code 
#38 —------------- - 
xhandler | Address of exception handler 
#3A 0 -------------- ~ 
| first : Address of first Rx workspace 
$3C 0 earn nw nnn 
nesting | RX nesting level 
#3D 00 #2------------ ~ 
object type | Type of first RX structure 
#3E 0 -------------- 7 
object : Pointer to the first Rx structure 
#40 een === === oe 
next process Address of next process record in a Ly 
‘of all | circular, one-way list of ALL process ° 
processes records. 
#42 --------------- 
‘last started Address of process record last started 
| by this process. 
#44 --------------- | 
“next process Address of next process record in a queue 
in queue (semaphore or ,scheduling queue) or nil 
| if this process is the last member or 
is not in a queue. 
#46 ~—-------------- 
queue Address of current or last semaphore 
queue 
#48 ~----~---------- 
current Interrupt currently being serviced. 
interrupt (-l1 if no interrupt in progress) 
level 
#4A SSS SSeS ne SS=== 
-Creator’s id See explanation below. 
#4B 0 --------------- 
| my id See explanation below. 
i. Leconimeiadaine 
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The field of the process record called "my id" (displacement >4B) is 
set to a value as follows. A count is kept of all processes’ started 
(stored in process management record). If this count is less than 256, 
then it is stored in "my id" when the process is first created. If 
this count is greater than or equal to 256 at the time a process’ is 
first created, then the most significant byte of the count is stored 
in "my id" of the new process record. 


The field of the process record called "creator’s id" (displacement 


4A) in a new process”7 record is set to the value of "my id" of the 
process which created the new process. 


A.3.2 Channel Record 
The following record is referenced by the executive record and 


subdirectory records. It is used to control the message flow from one 
process to another. 


message Address of a semaphore which signals 


present the availability of a message on the channel 


notify Address of a user defined semaphore (This 
field is set by a special channel routine. 


This channel routine will signal the notify 


semaphore if it has been initialized 

and a message was sent over the 

channel. This allows the user to create 
processes which can be notified when a 
message is present on one of several 
channels that the process services. 

The process can then perform conditional 
receives to determine which channel has 
the message) 


header list Address of the last message in a channel’s 
tail Circular buffer queue of messages. 


id Integer corresponding to a channels 
identification number. 


number The number of readers and writers currently 


connected | connected to the channel. 


link Address of next channel in list. 


A.3.3 Executive Record 


The following record exists once in Rx 
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and points to all other fundamental data structures. Every process 
record has a pointer to this record. 


#00 
#02 


#04 


#06 
#08 


#0A 


#0C 
#0E 
#10 
#12 
#214 
#16 
#18 


A.3.4 





channel 
directory 
mutex 
channel list 
pointer 
I/O 
semaphore . 
I/O 
list header 
message 
semaphore 
message 
fid 
Clock 
record ptr 


Address of active process. 


Address of ready queue. All ready 
processes are linked in this queue. 


Address of NO EVENT semaphore (used by inter > 
processing routines.) This semaphore has no 
waiters on it. 


Address of process management record. 


‘Address of heap record for all data space 


used by Rx 

Address of the exclusive access semaphore 
for channel list 

Pointer to the first channel on the channel 
list 

I/O subsystem semaphore 

I/O subsystem list header 

"Message" file identifier semaphore 


Address of file identifier for "message" 


Pointer to the clock record 


File Identifier Record 


Fach process has a unique file identifier (FID) record associated with 
it, one for every file variable it declares. The file identifiers 


allow 


the process to access the data structures required to implement 


I/O for a particular subsystem. The FID records for a process are 
linked together. 








link Pointer to next FID in the linked list 
#02 —---------------- 
| subsystem Pointer to the subsystem record associated 
| with the file 
#04 ---------------- 
status Status of the file 
#06 ---------------- 
state State of the file 
#08 ---------------- 
variables Pointer to the subsystem dependent variable 
record 
#0A ---------------- 
global frame Address of the process’s global frame 
#0C ---------------- 


A.3.5 FID Variables Record 


The file identifier (FID) variables record is a subsystem dependent 
structure. It contains the variables required for a given subsystem. 
These variables may be different for different subsystems, so the FID 
variables record will be unique for different subsystems. An example 
is the IPCSFID variables record described in subsection A.3.8.1. 


A.3.6 File Descriptor 
A file is implemented by the following record. In Microprocessor 


Pascal a file variable is a pointer to a file descriptor. This record 
is not used in RXKERNEL. 


#00 --------------- 
fill Not used 
#02 --------------- 
file name Pointer to the string containing the files 
name 
#04 --------------- : 
file name Length of the file’s name 
length 
#06 ---—------------ 
next Pointer to next element in the buffer 
#08 --------------- 
last Pointer to the last element in the buffer 
#0A --------------- 
line buffer Address of the file’s buffer 
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| file id ! Address of file identification record (FID) 
cE ee | 
| link Pointer to next file descriptor defined 
| within the same process 
#12 — ee ee oe ee ae --- “ 
type | Packed record defining file format, record 
| | format, file usage, and file compression 
#14 }+-----~-~-~---—--- 
state File state ( closed, open for reading, 
open for writing, or eof ) 
#15 }-------+-----~~-- 
packed data Terminate on error flag ( 1 byte ) 
File kind ( sequential, text, or random ) 
I/O in progress flag ( 1 byte ) 
#16 }----~----------- 
status Error class and reason 
#18 L~------------ 


A.3.7 Heap Record 


Each heap is administered through the following heap record. A heap 
record is referenced from each process record. 


# 


400° -sSe--——56-S55 
heap sema Address of semaphore ensuring mutually 
exclusive access to heap data structures 
#02 }-------- ----- | | 
minimum ptr. Value of smallest valid heap pointer 
#04 }------------- 
maximum ptr. Value of largest valid heap pointer 


A.3.7.1 Free Heap Packet 


A heap packet which is not allocated has the following format. 


size Size of this packet (16-bit logical 
value of number of bytes) | 


* Remainder of packet 




















A.3.7.2 Allocated Heap Packet 


A heap packet, which is allocated by a process, is referenced by the 
process through a pointer and has the following format. 


#-02 ~-------------- 
sizetl Size of this packet plus one (16-bit 
logical value of number of bytes) 
#00 }-------------- <-—- pointer 


* Remainder of packet 


A.3.8 Interprocess Data Structures 


These data structures are used exclusively to implement interprocess 
communication. The following data structures allow messages to _ be 
passed through channels. Note that these specifically apply to the 
File I/O Decoder and I/O Subsystems. 


A.3.8.1 IPCSFID Variables Record 
This record is accessed through a FID record. It contains’ the 


addresses of read parameters, the file”“s message buffer, and a pointer 
to the pathname record. 


#00 --------------- | 
read length Indicates the number of characters which 
pointer have been read 
#02 }------~--~--~~-- 
maximum Indicates the maximum number of characters 
length that can be read into a buffer 
#04 +—-.--.—--—-——~~ 
buffer Address of the buffer which contains the 
message 
#06 }+-------------- 
pathname Address of the unique pathname record for 
node the file 
#08 ++------~~------ | 
command Address of a related message record 
#0A L-------------- 








A.3.8.2 IPCSPort Variables Record 


This record is accessed through an IPC-subsystem record. It points to 
a linked list of pathname records, each containing the unique 
characteristics of a particular file. 


£00 j22soSoccn5eeecos 
mutex Address of the semaphore used to insure 
mutual exclusion when accessing the list 
'O2. boas lee ewes 
pathname node Address of the first pathname in the list 
£06: ooo eee | 


A.3.8.3 Pathname Record 


This record is accessed through either the pathname node field of the 
process IPCSFID variable record or the IPC$port variables record. The 
pathname record contains characteristics unique to a given file. Also 
contained are values used to access and synchronize access to the 
file“s channel. 


#00 --------------- 
mutex Address of the semaphore used to ensure 
exclusive access to the pathname record 
#02 }--------—------- 
Link Address of next pathname in linked list 
#04 --------------- 
length Number of characters in the file”s name 
#06 --------------- 
name Address of the string containing the file’s 
name : 
#08 }+--~--------~--- 
type Packed record defining file format, record 
format, file usage, and file compression 
#0A --------------- 
record size Maximum number of characters in a logical 
record 
#0C ---------~--+--- 
end of Boolean indicates if all producers have 
production closed on a channel 
#Q0E --------—-—---~---+ 7 
create Boolean indicates if file has been created 
called : 
#10 ---~---~----~..—-— 
end of Points to a semaphore used to synchronize 
consumption the closing of producers 
#12 L-~~~-..—-~....- 
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waiting Points to a semaphore used to synchronize 


; for create the creation of a file 
14 --------+------- : 
number of The number of processes writing to a file 
producers 
#16 --------------- 
number of | The number of processes reading a file 
consumers 
#18 ---------------+ 
umber connecte The number of processes connected to a file 
#1A +-------------- 
channel . Address of the unique channel associated 
with this pathname 
#1c 4-------------- 





A.3.9 Interrupt Record 


The interrupt records in Rx are _ stored in the workspace for the 
individual interrupt levels. In particular, Rll and R12 contain the 
addresses of the externalevent and altexternalevent semaphores. If no 
semaphore has been associated with the interrupt level, both of the 
registers will point to the NOEVENT semaphore (where there are no 
waiters present). R9 and R10 contain the 9900 context of the assembly 
event handler. If no handler has been specified, the WP portion of the 
vector is set to 0. 


400: paces Seana 
* 
* 
#0C }—-------- ~~~ ee 
level Interrupt level 
#0ER  ---------------- . | 
mpxptr Address of Rx executive record 
#10 +---~---—-—-+-—---—- 
wsptr Context workspace pointer 
BLD been eee eee 
WP 9900 context of interrupt handler 
If no handler, WP is set to zero 
#14 Li. ——.-----—= | 


PC Program counter of interrupt handler 
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| externalevent Address of EXTERNALEVENT 
a sema semaphore or NOEVENT 
a eas 7 
ltexternalevent Address of ALTEXERNALEVENT 
sema semaphore or NOEVENT 


A.3.10 Message Descriptor 


Interprocess messages are passed by means of pointers to the starting 
address of the message field in the message descriptor. The two words 
which precede the message field are used by the ipcS routines for 
synchronization and are normally not accessed by the user. The message 
descriptor is defined as follows: 


| 


#-04 --------------- | 
acknowledge Semaphore signalled when a message has been 
: processed 
#-02 }--~------------- 
link Address of next message ( used in the 
‘ circular buffer of a channel ) | 
00 }-------- ‘= 


message Variable length message field 


A.3.1l1 Message Record 


Interprocess communication data is transmitted through a message 
record. 


#00 ---~~+—~~-.———.— 
buffer Address of the message sent 
#02 --~------------- 
length Number of total bytes in the message field 
#04 L-~-~-~-~-—-~+-~—-~--- 
count Number of bytes actually sent in the 
message field 
#06 L-~-~~~-~~--—-—----- 
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A.3.12 Node Header Record 


The node header record defines one or more nodes associated with a 
given port. It is referenced by port constants records. Note that this 
record applies specifically to the File I/O Decoder and I/O 


subsystems. For further information, reference the Device Independent ° 


File I/O Package User”s Manual, MP386. 


#00 p--------------- : 
link ] Points to the next node header record 
#02 ---~----------- | 
node type Indicates the type of the node 
#04 --------------- 
node name Pointer to the string containing the nodes 
name 
#06 }--------------- | 
node name Length of the node“s name 
length 
#08 }--------------- 
* Subsystem dependent fields 


A.3.13 Port Constants Record 


This structure contains the constant values necessary in performing 
I/O operations with a particular device. Note that this record applies 
specifically to the File I/O Decoder and I/O Subsystems. For further 
information, reference the Device Independent File I/O Package, MP 


#00 --------------- 
link Pointer to next port constants record 
#02 ~--------------- 
interrupt leve Indicates the interrupt level of a device 
#04 }-------------- 
io address l Port address 1 ( used when appropriate to 
specify a memory mapped I/O port ) 
#06 }---------------- 
io address 2 Port address 2 ( used when appropriate to 
“a j specify a memory mapped I/O port ) 
06 Gewewea wee eee 
heap size Size of the heap packet allocated to the 
- subsystem 
#0A --------------- 
handler Address of interface handler 
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#0C p-------------- 


port name Address of the string containing the port’s 
name 
eBP : 
OR penn eee een nee 
port name Length of the port”s name 
length | 
+10 peewee teeta 
node header Pointer to the associated node header record 
#12 }-~-------~—-~---- 
* 
* Subsystem dependent fields 
* 
#14 WH... 


A.3.14 Port Variables Record 


The port variables record contains the variables necessary for I/O 
with a device. Since the required variables may be different for 
different devices, this structure is subsystem dependent. Note that 
this record applies to the File I/O Decoder and I/O Subsystems. 
Reference the Device Independent File I/O Conversion Package, MP386, 
for further information. | 


A.3.15 Process Management Record 


The following record is referenced by the Executive Record and exists 
once in Rx. 


#00 -p------------- 

utex semaphor Address of semaphore ensuring mutual 

: exclusion in process management 
#02 -------------- 

number of Number of started processes 
starts 

#04 =b}--~.~—---~~--- | 

termination Address of termination workspace 

ws 


A.3.16 Semaphore Record 


A semaphore is a pointer to a semaphore record described below. 


count Count of semaphore (returned by 
| SEMAVALUE function). 
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! waiters | Address of queue record in which 
waiting processes are enqueued. 


-BP 

#04 anime Sei eereniace 
! level Maximum value of priority which may wait 
) on this semaphore (32767 except when 
associated with an interrupt.) 

$06 ‘Gatetewnecennn 


A.3.17 Service Directory Record 


The service directory record provides the capability of accessing 
different code for different subsystem types. The fields in this 
record contain the addresses of the various subsystem routines. For 
example, the service directory record for the IPC subsystem contains 
the starting locations for each of the IPC routines. 


£60) eee eee esos . 
length Total size of this record ( Currently not 
used ) 
eee 
Sinit Address of xxxSinit routine 
£04 Leeceeoesiececss | 
S$connect Address of xxxS$connect routine 
a ee ee a eee _ 
sopen Address of xxxS$open routine 
( 
#08 +--------------- | 
Sread Address of xxx$read routine 
#0A t—--------------- ! | 
Swrite Address of xxx$write routine 
$0C: poececsesussea= _ 
| Sclose Address of xxx$close routine 
#0E +-------------- - 
Sdstatus : Address of xxx$dstatus routine 
$10) ececeseteeeeess 
| Sdisconnect | Address of xxx$disconnect routine 
#12 --------------—- 
Sabort io | Address of xxxSabortio routine 
Pid Geese tee i 
Screate Address of xxx$create routine 
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sdelete Address of xxxSdelete routine 
£16 eco aS | 
Sposition Address of xxxSposition routine 
a» ae ence ae 
Swait Address of xxxSwait routine 
ea ee nae 


A.3.18 Subsystem Record 


The subsystem record contains a pointer to the service directory 
record which is associated with a particular subsystem. Pointers’ to 
the port constants’ and variables are also included in the subsystem 
data structure. | 


#00 ------~——-----— 
link Pointer to the next subsystem record 
#02 --------------- , 
service Pointer to the associated service directory 
directory record 
#04 +---~-----~-~-~—~-- . 
port constants Pointer to the subsystem dependent port 
constants record 
#06 -—-------------- 


port variables | Pointer to the subsystem dependent port 
| variables record 


A.4 STACK DATA STRUCTURES 


The data structures described are used by Rx to maintain the stack 
structures in memory. These stack structures are necessary to support 
concurrency and reentrancy. 


A.4.1 Process Stack 


The stack for a process is allocated as two separate regions, the 
first is the stack frame for the process, and the second is the stack 
to be used by routines which are called from the process. The two 
regions have the following format: 


PROCESS 
STACK 
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Administration area for process 


---------~+----- Pee global frame 


process Stack frame for process variables 
stack frame 
ROUTINE 
STACK 
wee <-- stack base 
first Stack frame for first routine 
stack frame 
sania 
* | Stack frames of intermediate routines 
* 
2------------ <-- local base (R9) 
current Stack frame for currently active routine 


stack frame 
See <-- stack pointer (R10) 


* Rest of available stack 
* 
current 
workspace | 
mao <-- workspace pointer 
* 
“ Workspaces of intermediate routines 
* 
process 
workspace | 
------------- + <-- stack limit 


A.4.2 Stack Frame 


Each stack frame contains the values of the variables and parameters 
for a given routine. The stack frame consists of two regions, either 
of which may be zero length. A stack frame is shown on the following 


page: 
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A.4.3 


passed 
parameters 


local 
variables 


Process Mark 


<-—- RY 
Parameters pushed onto stack before 
calling routine 


Reserved storage for variables used 
within the routine 


The administration area below the frame of a process is used to _ hold 
information about the process. 


#-10 
#-OE 
#-OC 


#-OA 


#-09 


#-08 
#-06 
#-04 


#-02 


packed data 


—> Dp > ED SD GED Gap GD GED aw GD Gy a 
> DD ED GD ee ee oe ee a Ge 
=p GD oe CUD Gp ee GP C's ow Oe oO ow 


Pointer to the list of FID records 


Pointer to the list of files which is 
created during process termination 


Address of heap record for this process 


Boolean which is true if this process 
created this process’s heap, or is false 
if this process is sharing a nested heap 
(1 bit). 

Boolean equal to process heap termination 
flag (1 bit). 

Boolean equal to process start termination 
flag (1 bit). 

eee indicates if process has completed 
(1 bit). 

Lexical level of this process (5 bits). 


Number of references to this process 
frame by processes which can address 
this frame. 


Priority of this process 
Pointer to this process’s input file 


Pointer to this process“s output file 


Address of global frame of lexical parent 
if lexical level is 2 or greater. 
(otherwise zero) 

<--- Global frame pointer 
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A.5 ROUTINE DESCRIPTORS (CONTAINED IN PROLOGUE OF THE CODE) 


The routine descriptor contains information about a procedure, 
function, or process which is used when it is called. This information 
includes data such as the start of code, data frame size, parameter 
size, end of code, and the number of registers that need to be 
initiallized. 


A.5.1 Standard Procedure/Function Descriptor 


The procedure/function descriptor is used by the linkage routines when 
the routine is called. The first four fields of the process descriptor 
record are fixed and are always generated by the compiler. The 
remaining fields following the frame size may or may not be generated 
by the compiler and included in a process descriptor record. This will 
occur if the compiler can optimize the use of these fields in the 
code. The standard linkage supports the passing of parameters or local 
variables. 


#00 -—--------~---- 
prologue Displacement to start of code 
(bytes) 
#02 }------------- | 
epilogue Displacement to epilogue of routine 
(bytes) 
#04 = $-------~------- 
local Size of local variable portion of local 
frame (bytes) 
#06 $—------------- 
frame size Routine frame size (bytes) 
#08 $—-—----------- 
literals Literals Section 
mM $------------- 
routine Object code for routine; its location 
(nn) is determined by length of literal 
section | 


A.5.2 Optimized Procedure/Function Descriptor 


The optimized procedure/function linkage executes faster than the 
Standard linkage. However, this linkage does not directly support 
passing of parameters or local variables. : 


0 Zero value 
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A.5.3 Process Descriptor 


The data structure for a process is basically the same as that for a | 
procedure or function, containing several additional parameters’ for | 

System use. Note that the Executive will only look at the first four 
fields. The remaining fields can be used as the programmer wishes. If 
the remaining fields are used, it is suggested tHat they be listed in 














the order shown below. 
#00  peesesecececce 
prologue Displacement to start of code (bytes) 
$02 bees | 
epilogue Displacement to epilogue of process (bytes) 
$04 beeeedenueecse 
0 zero value 
#06 -------------- | 
parameter Size of passed parameters (bytes) 
size i 
#08 ------------- e 
frame size Process frame size (bytes) 
#0A -------------- | 
lexical Lexical level of process 
level 
£0C $esesaeeeee oes | | 
Priority Process Priority 
a er 
stacksize Stacksize of process (words) ; 
$10 }-------------- 
heapsize Heapsize of process’ (words) 
#12 }-------------- 
literals Literals section 
nn '------------- } 
start-up Start-up code for process; its | 
code location (nn) is determined by length 


of literals section 
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A.6 CLOCK DATA STRUCTURES 


The clock process (CLKINT) maintains an elapsed time field in memory 
along with a list of time elements which should be signalled at 
certain specified times. 


A.6.1 Clock Record 
The clock process increments a two-word integer value every 10.0053 


milliseconds. This two word integer is stored in a portion of common 
data space with the following structure: 


$00 i¢eeeeveteeeece 
elapsed time Integer length of current execution time 
(two word value with most significant word 
first) 
$04 bemeenscecoess : 
queue Address of the first clock service record 


waiting on the clock for some event 


A.6.2 Clock Service Record 


A clock service record is created for each process performing a timed 
wait or delay function. These time elements are maintained in a list 
pointed to by "queue" in the clock record structure. When a clock 
service record is initially inserted into this list a field is set 
indicating a length of time that the structure is to remain in the 
waiting queue. The time is decremented on each interrupt. When the 
length of time to wait is zero the clock service record is’ removed 
from the queue list and the event (such as a delay) is signalled. 


#00 -------------- + 
link Address of next clock service record in the 
waiting queue (twait_q list) 
#02 }------------- 
sema Address of semaphore to be signalled 
when time has expired 
#04 [[---~---------- 
time left Time remaining until the semaphore 
should be signalled (two word value 
with most significant word first) 
#08 [[-------------- 
timed out Boolean flag set to true when the 
“time left” reaches zero 
signalled Boolean flag set to true when “sema” is 
signalled 
#0A Pern -- = | 
elay semaphore| Address of user semaphore used to implement 
| delay procedure 
#0C bL-------------= 
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APPENDIX B 


Rx ERRORS CODES, ERROR RECOVERY, AND EXCEPTION HANDLING 


B.l1 GENERAL 


As a process executes, it may encounter an exception such as' division 
by zero or subscript out of range. The ability of a process to deal 
with and possibly recover from exceptions is called exception 
handling. The mechanism by which a process can recover from exceptions 
and reprocess lost work is explained in this section. 


'B.2 EXECUTIVE RTS DETECTED ERRORS 


The Rx RTS passes error codes to RxBUG when a system failure occurs, 
and a message is displayed by RxBug in the form: 


ERR = Xxyy 


where xx is the class code, and yy the reason code. 


All class codes are unique, with the expection of System Crash Codes 
and Run-Time Support errors. Both are: 00. The difference is 
distinguishable by the fact that System Crash Codes do not appear in 
the process record error field; i.e., >36 bytes from the start of the 
process record. 


If a SHOWHEAP command is performed on the process record of the active 
process, the error code will be in the fourth row at the _ fourth 
position . A zero in this position means no error was written to the 
process record. 


NOTE: a zero in the fourth position of the fourth row does not mean no 
error occurred, but simply that one wasn°t detected. A DR command 
Shows all registers. Check Register 0 of the current workspace to 
identify such an error. A non-zero value in Register 0 is indicative 
of a System Crash error. Table B-1 lists all RTS-detected errors and 
their meanings. Table B-2 explains the meaning of each reason code and 
provides remedial action, if applicable. 








Class 
(xx) 


CODE 
Reason 
(yy) 


ERROR CODES. 


MEANING 


SYSTEM CRASH CODES (00) (APPEAR IN RO ONLY) 


00 
00 
00 
00 
00 
00 
00 
00 


00 
00 
00 
00 
00 
00 
00 
00 
00 
00 
00 
00 
00 
00 


Ol 


01 
02 
03 
04 
05 
06 
07 
08 


Unable To Boot System 

No Exception Handler 

No Interrupt Handler 
Illegal Interrupt or XOP 
Scheduling Queue In Error 
ROM/RAM Partitioning Error 
Process List In Error 

Heap In Error 


RUN-TIME SUPPORT ERRORS (00) 


02 
04 
05 
06 
07 
08 
09 
OA 
OB 
OC 
OD 
14 
15 
16 


YY 


Stack Overflow 

Division By Zero 

Floating Point Error 

Set Element Out Of Bounds 
Assert Error 

Missing OTHERWISE In CASE 
Array Index Error 

Pointer Equals NIL 
Subrange Assignment Error 
LONGINT Array Index Error 
LONGINT Subrange Error 
Halt Called 

String Index Error 

String Length Error 


USER DEFINED ERRORS (01) 


Defined by the user as a Parameter to the 


RX procedure: EXCEPTION 


(Continued) 

















TABLE B-l. ERROR CODES (Continued). 


CODE 
Class Reason 
(xx) (yy) MEANING 
SCHEDULING ERRORS (02) 
02 Ol Invalid Queue 
02 02 Priority Error 
SEMAPHORE ERRORS (03) 
03 01 Invalid Semaphore Structure 
03 02 | Count Error 
| 03 03 Operation Error 
| 03 04 Count Overflow 
03 05 Priority Error 
04 02 | Level Invalid 
04 03 Semaphore Invalid 
, 04 04 No Interrupt Handler 
aa (04 05 No Dedicated Interrupt Workspace 


(Rx 1.1) 


PROCESS MANAGEMENT ERRORS (05) 


05 03 Invalid priority 
05 04 Negative Stack Size 
05 OB No Memory 


EXCEPTION HANDLING ERRORS (06) 


06 01 Handler Not Established In Process 

06 02 Handler Cannot Have Parameters 

06 03 Not Enough Memory For Handler 
(Continued) 





TABLE B-1. ERROR CODES (Continued) 


Reason 
(yy) 


MEANING 


MEMORY MANAGEMENT ERRORS (07) 


CODE 
- Class 
(xx) 
07 O1 
07 02 
07 03 
07 04 
08 01 
08 02 
08 03 
08 04 
08 05 
08 06 
08 07 
08 08 
08 09 
08 OA 
08 OB 
09 01 
09 02 
09 03 
09 04 
09 05 
09 06 
09 07 
10 O1 
10 02 
10 03 


Heap Pointer Invalid 
Heap Overflow 

Invalid Packet Pointer 
Attempt To Free A Packet 


FILE I/O ERRORS (08) 


File Not In State For Reading 

File Not In State For Writing 

Sequential End Of File 

Error In Opening File 

Read Error 

Write Error 

No Memory For File Descriptor 

No Memory For Pathname 

File Not Closed 

Invalid Parameter Passed To 
FSSTLENGTH 

Not A Text File 


TEXT I/O ERRORS (09) 


Text Conversion Parameter Out Of 
Range 
Text Conversion Field Width 
Too Large 
Incomplete Text Conversion Data 
Invalid Character In Text Field 
Text Conversion Value Too Large 
Text Read Past End Of File 
Text Field Exceeds Record Size 


CHANNEL ERRORS (10) 


No Memory For Buffers 
No Memory For Semaphore 
No Memory For Channels 


(Continued) 








TABLE B-1l1. ERROR CODES (Continued). | 


CODE 
Class Reason 
(xx) (yy) MEANING 
FILE I/O DECODER ERRORS (ll) 
11 01 Empty File ID List 
ll 02 File ID Not Found 
ll 03 File Not Released 


INTERPROCESS COMMUNICATION ERRORS (12) 


12 01 No Heap For Pathname Record 
12 02 No Heap For Name Field 
12 03 No Heap For File Variable Record 


B.2 EXPLANATION OF REASON CODES 


Table B-2 provides a detailed explanation for each reason code given | 
in Table -l. | , 





TABLE B-2. EXPLANATION OF ERROR REASON (yy) CODES. 


SYSTEM CRASH CODES (00) 


Non-recoverable errors are defined to cause a system crash, which 
results in the execution of the system crash code that is specified by 
Parameter $SYSCR in the user”s CONFIG module (See Section 8). A 
description of these errors follow: 


01 Executive RTS is unable to boot the system, probably because 
Of insufficient memory. 


02 A system, program, Or process fails without having 
established an exception handler. | 


O03 An interrupt occurs at a level for which no handler has been 
specified at the time of the occurrence of the interrupt. 


04 An unimplemented interrupt or XOP occurs and cannot be 
serviced. 





05 


06 


07 


08 


02 


04 


05 


06 


07 


TABLE B-2. EXPLANATION OF ERROR REASON (yy) CODES. 


The scheduling queue has been destroyed; further scheduling 
is impossible. 


RAM made available to Executive RTS is found to be in error. 
An address specified to be RAM is either bad, ROM, or 
unimplemented memory. 


The process list is in error. 


In attempting to deallocate the resources associated with a 
process, the process record of that process could not be 
found in the list of all active processes. The probable 
cause is the destruction of system data structures. 


The heap pointer is invalid. An invalid heap packet pointer 
was encountered while attempting to deallocate a process. 


RUN-TIME SUPPORT ERRORS (00) 


Stack Overflow: This error occurs when the allocated stack 
memory region is exhausted. The problem. can normally be 
remedied by increasing the stack size parameter. 


Division By Zero: This error occurs when division by Zero is 
detected. The offending expression should be checked and 
corrected to avoid this error. 


Floating Point Error: This error occurs when a REAL value is 

too large or too small to be represented. The range of 

oteese values that can be represented is about 1.0E-78 to 
-OE75. 


set Element Out Of Bounds: This error indicates that a member 
of a set has an ordinal value less than 0 or greater than 
1023. This problem can be solved by restructuring the set or 
breaking it into more than one set if necessary. 


Assert Error: This error occurs when the expression in an 
ASSERT statement evaluates to "false". Either the expression 
was improperly formed or a logical error occured at’ some 
point in the program. 














08 


09 


10 


11 


12 


13 


20 


TABLE B-2. EXPLANATION OF ERROR REASON (yy) CODES. 


Missing OTHERWISE in CASE: This error occurs when the 


selector expression in a CASE statement does not evaluate to 


any of the case labels present and there is no OTHERWISE 
Clause to be used as the default statement. If there are no 
logical errors in the program, an OTHERWISE clause should be 
added so that unanticipated label values will be handled 
uniformly. 


Array Index Error: This error occurs when an array index is 
out of bounds for the array. The error may have been caused 
by an incorrectly formed index expression(s). Alternatively, 
the array definition may be incorrect. 


Pointer Equals NIL: This error occurs when ae reference is 


attempted through a pointer which has the value NIL. (No 
check is made to ensure that the pointer points to a valid 
((allocate)) heap packet.) To avoid this error, make sure 
that all pointers have a valid, non-NIL value before they are 
used. 


Subrange Assignment Error: This error occurs when a_ subrange 
variable is given a value that is outside its range. This 
could be the result of an unanticipated assignment or 
function result. Expressions should be examined to ensure 
that their values are in bounds; alternatively, the subrange 
bounds may have to be altered. 


LONGINT Array Index Error: This error occurs when a LONGINT 
array index is out of bounds. 


LONGINT Subrange Error: This error occurs when a  LONGINT 
subrange variable is given a value that is outside its range. 


HALT called: The procedure HALT has been called. 


USER-DETECTED ERRORS (01) 


A user error can be forced by calling the routine EXCEPTION 
with its class code parameter set to 1 to denote a 
user-detected error. The process which executes this routine 
fails with some designated reason code (as specified by the 
user aS a parameter to EXCEPTION). 
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02 


01 


02 


03 


04 


05 


02 


TABLE B-2. EXPLANATION OF ERROR REASON. (yy) CODES. 


SCHEDULING ERRORS (02) 


Invalid Queue: This error should not be seen by the user. It 
indicates a system error which probably resultd from Rx code 
being accidently modified. 


Priority Error: This error occurs if SETPRIORITY is called 
with an interrupt priority (in the range 0 to 15). The 
Priority of a process cannot be set to an interrupt priority. 


SEMAPHORE ERRORS (03) 


Invalid Semaphore: This error indicates that a structure that 
was passed to a semaphore routine is not a valid semaphore. 
The error occurs primarily in cases when a semaphore is’ used 
before it has been initialized by INITSEMAPHORE or after it 
has been terminated by ‘TERMSEMAPHORE; otherwise it is a 
run-time support error which may be a result of system data 
structures being accidently destroyed. 


Count Error: This error can occur when INITSEMAPHORE is 
Called with a count value that is not in the range 0 to 
32767. A semaphore cannot be initialized to a negative value. 


Operation Error: This error can occur when a_ semaphore 
Operation is attempted and fails. TERMSEMAPHORE can produce 
this error if the semaphore being terminated has waiters. 


Count Overflow: This error occurs whenever the | counter 
associated with a given semaphore becomes equal to 32767, 
meaning that no more events can be signaled until some 
waiting processes perform a WAIT. 


Priority Error: This error occurs when a process attempts to 
WAIT on a semaphore that is associated with an interrupt and 
the priority of the process is less urgent than the level of 
the interrupt. 


INTERRUPT ERRORS (04) 


Level Invalid: This error occurs when the priority passed to 
one of the routines ALTEXTERNALEVENT, EXTERNALEVENT, 
NOALTEXTERNALEVENT, NOEXTERNALEVENT, ASSEMBLYEVENT, Or 
NOASSEMBLYEVENT is not in the range 1 to 15. 
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04 
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01 


02 


03 


TABLE B-~2. EXPLANATION OF ERROR REASON (yy) CODES. 


Semaphore Invalid: This error results if an invalid semaphore 
is passed to ALTEXTERNALEVENT or EXTERNALEVENT. 


Interrupt Not Handled: This error occurs when an interrupt is 
Signaled and there is no process waiting to service the 
interrupt. 


PROCESS MANAGEMENT ERRORS (05) 


Not Started - Invalid Priority: This error occurs when it is 
not possible to start a user process because the priority 
given in the concurrent characteristics for the process is 
not in the range 0 through 32766. 


Not Started - Negative Stacksize: The stacksize given in the 
concurrent characteristics for the process must be 
non-negative. 


Not Started - No Memory: This error indicates there was. not 
sufficient memory for allocation of data structures necessary 
for starting the process. 


EXCEPTION HANDLING ERRORS (06) 


Exception Handler Not Established From Program Or Process: 
The procedure ONEXCEPTION must be called from a program or 
process module, not a procedure or function. 


Exception Handler Cannot Have Parameters: The routine 
identified as an exception handler must not have parameters. 


Exception Handler Local Variables Too Large: The exception 
handler specified to ONEXCEPTION requires more. stack space 
than is available in the process in which it will execute. 
Either increase the STACKSIZE concurrent characteristic or 
decrease the size of the local variables of the exception 
handler. 
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TABLE B-2. EXPLANATION OF ERROR REASON (yy) CODES. 


MEMORY MANAGEMENT ERRORS (07) 
Invalid Heap: This error should only occur if the integrity 
of the user”s system heap is accidently destroyed either by 
run-time support code or by the user’s code. 


Heap Overflow: This error indicates that the available heap 


space has been exhausted. 


Heap Packet Error: This error occurs when a heap packet is 
passed to a routine such as DISPOSE and the heap packet is 
invalid. 


Invalid Packet Error: This error occurs when an attempt is 
made to free a packet that is no longer allocated. 


\ 


FILE I/O ERRORS (08) 
following errors pertain to (Pascal) file management. 


File Is Not Open For Reading: This error occurs when an 
attempt was made to read from a file which was not open _ for 
reading. A file is opened for reading by using RESET. 


File Is Not Open For Writing: This error occurs when an 
attempt is made to write to a file which was not open _ for 
writing. A file is opened for writing by using REWRITE. 


Sequential Read Past End Of File: This error occurs when an 
attempt is made to read past the end of a sequential file. 


Open Error: This error occurs when an attempt to open a_ file 
fails. 


Read Error: This error occurs when a read operation fails. 
Write Error: This error occurs when a write operation fails. 
No Memory For File Descriptor: This error occurs when there 
is not sufficient memory space with which to allocate a file 
descriptor. 

No Memory For Pathname: This error occurs when system memory 


cannot be obtained in which to save the pathname associated 
with a file variable. 
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TABLE B-2. EXPLANATION OF ERROR REASON (yy) CODES. 


File Not Closed: This error occurs when a file routine, which 
must only operate on a closed file (FSSTLENGTH for example) 
is passed an open file variable. 


Invalid Parameter Passed To FSSTLENGTH: This error occurs if 
FSSTLENGTH was called with a component length less than one. 


Not A Text File: This error occurs when a text file operation 


is attempted on a sequential or random file. ( For example, 
FSSTLENGTH can only operate on text files.) 


TEXT I/O ERRORS (09) 


Text Conversion; Parameter Out Of Range: This error occurs 
when a parameter to an encode or decode routine is out of 
range. For example, the index parameter must be a positive 
integer. 


Text Conversion; Field Width Too Large: This error occurs 
when a field width in a write statement is larger than the 
logical record length of the file. 


Text Conversion; Incomplete Data: This error occurs when a 
data value read or decoded is syntactically incomplete, for 
example, the value "1.0E" given for a real number. 


Text Conversion; Invalid Character In Text Field: This error 
occurs when a field being read contains a character which is 
invalid for the particular data type, for example, the 
Character "." when reading an integer value. 


Text Conversion; Value Too Large: This error occurs when some 
data value being read is too large to be represented as the 
Particular data type, for example, attempting to read "32768" 
as an integer value. 


Text Read Past End Of File: This error occurs when an attempt 
is made to read past the end of a text file. 


Text Field Exceeds Record Size: This error occurs when a 


specified field width is greater than the logical record size 
of the file. 


ee EE ET en Oe 








TABLE B-2. EXPLANATION OF ERROR REASON (yy) CODES. 


CHANNEL ERRORS (10) 


01 No Memory For Buffers: This error occurs when there is no 


memory available for allocating message buffers in calls to- 


CSALLOCATE. 


02 No Memory For Semaphores: This error occurs when there is no 
memory available for allocating channel synchronization 
semaphores. This error may be generated from calls to CSINIT 
or CSALLOCATE. 


03 No Memory For Channels: This error occurs when there is no 
memory available for allocating channel records in calls to 
CSINIT. 


FILE I/O DECODER ERRORS (11) 


These errors are returned by the I/O decoder routines. Complete 
information on I/O decoder errors can be found in the Device 
Independent File I/O (DIF) User”’s Manual. 


Ol Empty File Identifier List: The list of all file identifiers 
allocated in a process was empty when DSFIDRELEASE was called 
to deallocate a file identifier record. The probable cause is 
that DSDISCONNECT has been called to deallocate ae file 
identifier that has already been deallocated. 


O02 File Identifier Not Found: D4FIDRELEASE was unable to find a 
file identifier in the list of all file identifier of the 
Process in which it was allocated. The probable cause is that 
DSDISCONNECT has been called to deallocate a file identifier 
that has already been deallocated. 


03 File Identifier Not Released: Routine DSTERM has been called 
during process termination to close and disconnect all files 
that are active; for some file the associated file identifier 
was not deallocated. The probable cause is an I/O subsystem 
whose disconnect entry did not call D$FIDRELEASE. 


INTERPROCESS COMMUNICATION ERRORS (12) 


01 No Heap For Pathname Record: This error occurs in IPCSCONNECT 
when there is no memory available for allocating pathname 
records. 


* i. 
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TABLE B-2. EXPLANATION OF ERROR REASON (yy). 


No Heap For Name field: This error occurs in IPCSCONNECT when 
there is no memory available for allocating the name _ field 
found in the channel record. 


No Heap For File Variable Record: This error occurs in 
IPCSCONNECT when there is no memory available for allocating 
the file variable record. 


No Heap For Port Variables: This error occurs in IPCSINIT 
when there is no memory available for allocating the port 
variable record. 
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APPENDIX C 


RX ROUTINE TEMPLATES 








C.1 GENERAL 


This section describes the Rx linkage conventions, and contains 
templates for Rx processes, standard procedures and functions, and 
optimized procedures and functions. Items in upper case must be 
specified as shown; items in lower case must be specified by the user 
(i.e. the user must choose names for labels, and values for stack and 
heap sizes, etc.). Lines starting with asterisks ("*") are comments 
and need not be included in the source. Parts of the templates. are 
numbered, and these numbers refer to notes in paragraph C./7. 


C.2 TEMPLATE FOR A PROCESS 


The following template specifies the format of an Rx process. 


G)}———> IDT “proces” 


HK KK KKK ERR ERK EERE IRR EEE ERERE EKER RK 


* -- MODULES DEFINED -- _, 
KREKKEKKEKKEKEKEKKEEKEKKEKREEKEKREREKRKEEKEKKKKEKEKKKKRKRKKRKEKRERRKE 


DEF proces 
KRAEEKEKKKEKEKEEKEEEEEKREEKEEEREEEEEEEEEKEKKEEEREKKEEKKKKKKEKEKK KEK 


-* ~- EXTERNAL REFERENCES -- * 
KEEKKKEEKKEKKEEKEEKEEEKKEKEEEKEEKEKKEEEKEREEKERKKRR KKK KES 


REF CALLS 
REF SSPRCS 
(3) ~ )REF ESPRCS 


REF EXITSP 


REF ... OTHER SYSTEM AND 

REF ... USER DEFINED 

REF ... SYMBOLS REFERENCED 
KHKKEKEKEKKEKKEKEKKREKEEKEEKEKREEKEEEKEEEKEKEEKEKEKRKEEKKKRKKESE 
* | -- REGISTERS -- * 
KHKKEKEREKKEEEEREKEKEKEKEEEEEREEEKEREEKEKAEKEREREEEEEKEEERERES 
PR EQU 7 REGISTER 7 POINTS TO PROCESS RECORD 

@ CODE EQU 8 REGISTER 8 POINTS TO CODE BASE 

LF EQU 9 REGISTER 9 POINTS TO LOCAL FRAME 
SP EQU 10 REGISTER 10 IS STACK POINTER 





Heke Ke HK KK III IKE RRR RRR RK KE 


-- PROCESS DESCRIPTOR == * 
RAHRKKKKKEKEREKREREREREKREEREREKREKEKERKEKEKEERARKRKRKKEKKEKKRKKRRKERKEK 


* 


@——> 
(6) -proces 
7) 






frmsizZ 


lexlvl 
(2% priori 


PSEG 
EQU 

DATA 
DATA 


$ 
prolog-proces 
epilog-proces 


DATA 0 


DATA 
DATA 
DATA 
DATA 
DATA 
DATA 


>nnnn 
>nnnn 
>nnnn 
>nnnn 
>nnnn 
->nnnn 


OFFSET TO FIRST STATEMENT 
OFFSET TO TERMINATION CODE 
ZERO FOR PROCESSES 

SIZE OF ARGUMENTS (BYTES) 
TOTAL FRAME SIZE (BYTES) 
LEXICAL LEVEL 

PROCESS PRIORITY 

PROCESS STACKSIZE (WORDS) 
PROCESS HEAPSIZE (WORDS) 


Ieee eee EERE EE LE EEE RARER EEE ERE SEER ERE L ERR AERA AREER EERE RARE EE SS 


-- USER DATA -- ™ 
RHRKKKKKREKRIKKRK KEKE KEKEKREKRKEKAKEKRKEKKRKEKAKKE 


4’ estksiz 
Ii)’ »shpsize 


* 


aaa 


any user defined constants appear here 


Lee ee ee eee eee eee E RE RE RE RE EEE REE E LER EEE EEE ERE ARERR EEL EER RAE ES FY 


-- PROCESS START CODE -- * 
KKKKKKKKKEKKKEKEKRKERKREAKRAEAKREKRKKKR KKK KRKKERKKRKRKRKKRKRKRKKRARRRE 


(18)-—prolog EQU 
MOV 


* 


0393) 


MOV 
MOV 
MOV 
MOV 


| DATA 
CEE Tee T eT TT TTT TTT TTT TTT TTI TTT TTT TTT TTT TTT TTL 


-- USER CODE -- 
KH KKKKKKKEKKKEKEKKEKRAKEAKEKAKKEKKKR KK KKK KKK KKK KKK KKK KKREK 


* 


Cael 


—— 


MOV 
MOV 


MOV 
MOV 


DATA 


$ 


@frmsiz-proces (CODE) ,*SP+ PUSH FRAME SIZE, BYTES 
@lexlvil-proces (CODE) ,*SP+ PUSH LEXICAL LEVEL 
@priori-proces (CODE) ,*SP+ PUSH PRIORITY 
@stksiz-proces (CODE) ,*SP+ PUSH STACKSIZE, WORDS 
@hpsize-proces (CODE) ,*SP+ PUSH HEAPSIZE, WORDS 


CALLS ,S$PRCS 


*LF,@<ga> 
@2 (LF) ,@<ga> 


Rl, *SP+ 
R2, *SP+ 
CALLS, routin 


START THIS PROCESS 


Sample references to arguments 


GET 1ST ARGUMENT 
GET 2ND ARGUMENT 


A typical process call: 
PASS 1ST ARGUMENT 
PASS 2ND ARGUMENT 
CALL THE PROCEDURE 


“routin” must appear above 
in a REF statement. 





ee 








KKEKKEKEKEKEEEEKEKEEEK KKK 


* -~- PROCESS TERMINATION CODE -- * 
KEREEKKKEKEKEKEEEEKEEEEKEKREKKEKKKKKKEKEKKKEKRKKRREKEKKEKRKEKKKRKKKRKRKES 
epilog EQU §$ 
MOV @lexlvil-proces (CODE),*SP+ PUSH LEXICAL LEVEL 
| para CALLS , ESPRCS TERMINATE THIS PRCS 
B @EXITSP EXIT 
END 


®® © 


C.3 TEMPLATE FOR A STANDARD PROCEDURE 


The following template defines the format for a standard Rx procedure. 


© 


IDT “proced” 
KREKKEKEKEKKEKKEEEEKEEEEKEEEEKEKKEKEREKEKEKKKEKKKEKEKKKEKKKEKRKEKEE 


* =-- MODULES DEFINED -- * 
KREKEKEKEKERKKEKEEKEEKEEKEEKHKKKKEKEKEKKKREKEKKK KKK 
(2) DEF proced 
KEKEKKEEEKREEEEKEEEEKEKEKEKEKEEKEEEKKEEEKEKKKKREKRKRKREEKEEKEEEE 
* -- EXTERNAL REFERENCES -- * 
KEEEKKEKEKEKEEEKKEEEEKEKEKEEEKEEEKKREKKEEEEEKKEKKEKRKKKKKKKEK KKK 
REF CALLS 
@ REF SS$PRCS 
REF ESPRCS 
REF EXITSP 
REF ... OTHER SYSTEM AND 
REF .ee USER DEFINED 
REF .e. SYMBOLS REFERENCED 
KKEKKREKEKEKEKEKREKKKEEEEEEEKEKEEREKKEEKKEKEEEKKRAREEKKEEREREEE 
* -- REGISTERS -- * 
HHKEKKKEKKEKEKKEEKKEEKEKREKEKREKKEEKEKEEKEEEKREEKEREKRERKEREREEREKEEKRKEREKEKK 
PR EQU 7 R7 POINTS TO PROCESS RECORD 
CODE EQU 8 R8 POINTS TO CODE BASE 
LF EQU 9 RI POINTS TO LOCAL FRAME 
SP EQU- 10 R10 IS THE STACK POINTER 
* 


KEKEKEKKKREKKEEEKEEEEEKREEKEREKEKEEKEEKEKEEKKEERKEKEEKRKKEKERKEKRKEKKRESE 
to -- PROCEDURE DESCRIPTOR -- * 
KEEKKEEKKEEEEKEKEEKEREKREKKEKEEEEREKEEEKAREKEKRKKRKKKRKEKKEKKRKKRKRKEK 

@———» perce 

©-~ proced EQU $ 

@——+_ DATA prolog-proced © OFFSET TO FIRST STATEMENT 





() DATA epilog-proced OFFSET TO TERMINATION CODE 

@)———_ DATA >nnnn SIZE OF LOCAL VARS (BYTES) 

@——~__ DATA >nnnn LOCAL FRAME SIZE (BYTES) 
KHKEKKEKKEKKEEKKEKEEKEEKKKEEKEKEKEKREEKEKKKEEEKKEKKKKEKEKEKKKKKKKKRKEK 
* ' == USER DATA -- * 


HREKEKKEKEKEEKKEKKEKEKEEEEEKEEEKKKEEKEKEKEKEEREEKEEERKEKKEKKKRRKRKRKEKEKEEE 


; @—-}.-" | any user defined constants appear here 


Nene? 


| 











TRERESERESASE EE ELEE EEE SESE SEE EEE EEE AREER ERR EEE RELEASE RE RESALES SE 


. -- USER CODE -- * 
Pe eee EE ESC RESE SE SCE EES EES ERE CEE AR SAREE SESE ERE ESSE SESE ERE SESE EES 
(18)=prolog EQU §$ 
e@.;°e e 


wouide : Sample references to arguments 


OD MOV *LF,@<ga> GET 1ST ARGUMENT 
0) ™ \MOV @2(LF) ,@<ga> GET 2ND ARGUMENT 
gare A typical procedure call: 
MOV R1,*SP+ PASS 1ST ARGUMENT 
Qi} {MOV R2,*SP+ PASS 2ND ARGUMENT 
DATA CALLS$,routin CALL THE PROCEDURE 
peas “routin® must appear above 
aes in a REF statement. 


Lee ee eee eee EEE EERE E SESE ESLER ERE REE E SER E RRR ESLE REESE ESE SE ES 


id -- PROCEDURE TERMINATION CODE -- ~ 
KRHA RKKKEKRKKR KKK KKK KKK 


epilog EQU $ 
B @EXITSP EXIT 
END 


C.4 TEMPLATE FOR A STANDARD FUNCTION 


The following template defines the format of a standard Rx function. 


(.}———_> IDT “*functi’ 


KRHREKEKKKKKEKKKKEKKREREKKKKKERAKRERKRRRKRKEKKKKKKKKKKKKKKRRRKEEK 


x -- MODULES DEFINED -- * 
Lee eee eee eESEREREE RSE REL E EE SLE REEL ER EERE ERE REE REESE R ESE ERE SRE SY 


DEF functi | 
KkekkRKKRRKRKRKKRKRKRKRKKRKE KKK KKK KRKRKRKRKRKRKRKKRRKRRKRKRRRRRRRIE 


* -- EXTERNAL REFERENCES -- * 
ree eeeeeeeeeeee EEE LE ESLER EEE SELES ESE ERS AR AR ARARR ERE ARE RES E SERRE ES 
REF CALLS 
. REF SSPRCS 
G)— ——"" ) REF ESPRCS 
REF EXITSn (EXITS1 OR EXITS$2) 
REF ... OTHER SYSTEM AND 
REF ... USER DEFINED 
REF ... SYMBOLS REFERENCED 
RkeRKRKKKKRKKRKKRKRKRKRKKRKRKKR KKK KK KKK KKK KKK RRR KKK RRR ES 
* -- REGISTERS -- * 
KREKKKRKEKKRKRKRKRKKRKRKRKKRKRKRKRKR KK KKK KKK RRR KKK KR 
PR EQU 7 R7 POINTS TO PROCESS RECORD 
CODE EQU 8 | R8 POINTS TO CODE BASE 
LF EQU 9 RI POINTS TO LOCAL FRAME 
SP EQU 10 R10 IS THE STACK POINTER 


c-4 

















KREEKREKEKEKEKEKEKEKEKEEEEEEEEEREEREEEEKEEEEEEEKEEEKEREKKKKARKKKES 


* -- PROCESS DESCRIPTOR == * 
KEKE KKK KEK KEK KE KEE KEKE EKER EEE KR EKER ERR KREEREEKREEEEKRERRE 


Oe functi EQU $ 





DATA prolog-functi OFFSET TO FIRST STATEMENT 
(8)——_—_—_——_ DATA epilog-functi OFFSET TO TERMINATION CODE 
DATA >nnnn SIZE OF LOCAL VARS (BYTES) 
DATA >nnnn LOCAL FRAME SIZE (BYTES) 
KRREEKKEKKRKKKKEKEEEKKEKKEKKRKEKEKEKKRKKKKKKEKKKKKKKKKKRRKKKRKRKKR KKK E 
* -- USER DATA -- * 


KREKKKKKEEKEKEKKEKEEEKKEEEKKKEEEEEKKEEEKEREKEKERRKERKKKKEEEERKKEKEKEEKESE 


a7-——— ded any user defined constants appear here 


, KKEKKEKKEEKEKKKREEKEKEKEEEKEKEEKEEKKKKKKEKKEKKKKRKKKKKKKKR KKK 


* -~ USER CODE -- * 
HKHEEKKKKEKKEEKKEKEKEEKEKEEEEREEEKEEEEKEREEKEEEEKEEKEKEREKRKEEKEKRKKEEKEEEK 


(gm prolog EQU $ 


seer Sample references to arguments 
, MOV *LF,@<ga> _ GET 1ST ARGUMENT 
G0) ™ )MOV @2(LF) ,@<ga> GET 2ND ARGUMENT 
aie A typical function call: 
MOV R1,*SP+ | PASS 1ST ARGUMENT 
MOV R2,*SP+ PASS 2ND ARGUMENT 
(2m {Mov R3,*SP+ PASS 3RD ARGUMENT 
DATA CALLS, functi CALL THE FUNCTION 
MOV *SP,@RESULT SP POINTS TO RESULT (R10) 
ee “functi” must appear above 
ae in a REF statement. 


RKEEKKEKEKKEEKEKEKEEKEEEKEKEKEEEREKEKEKEKKEEEEKEREKRKEKEKEKREKKKKEESK 


i ; -- FUNCTION TERMINATION CODE -- 
FHKE REKEEKEKEREKKKRREKKEEEKKKEEKEKEEKEKEKEKEEREKERE KEKE RKEKEEEEER 


@}™epilog EQU $ 
o @EXITSn RETURN RESULT OF LENGTH n 
G6 DATA >mmmm OFFSET INTO LOCAL STORAGE 


> END OF THE DESIRED RESULT 


C.5 TEMPLATE FOR AN OPTIMIZED PROCEDURE 


The following template defines the format of an optimized Rx routine 
linkage (sometimes called a "special" linkage). A negative or zero 
value in the first word of the routine indicates that the routine uses 
an optimized linkage. A new workspace is allocated, and registers R/, 
R8, RY, and R1O are initialized, but no new stack frame is allocated. 
Instead, the routine uses the caller”s stack. The caller’s stack 
Pointer is reset, by adding the first word in the routine to the 


C-5 








caller’s R10. An optimized procedure may not call any other procedures 
or functions. 


IDT “proced~ FOR OPTIMIZED PROCEDURE 
HHH KEKE REE KERREREKREKREKEEKREKEKREKKR KEK KKK KEKE 
i -~- MODULES DEFINED -- * 


TREE REESE E EEE LEE EERE ERE EEE ERE REE EL ELE REE ER ERE SEER EES ESE LESS ES 


DEF proced 
ree ee eeEeRERERERE RES E SELES ESE ES EEE SEE ESSERE SEER ERE EERE SER ER EE SY 


* | -- REGISTERS --  * 
(eee eeeeeEEERRERERESRE RE REESE SER E ERE REESE R LARS ERE LER ERE RAS ERE SSE SY 
PR EQU 7 R7 POINTS TO PROCESS RECORD 
CODE EQU 8 R8 POINTS TO CODE BASE 
LF EQU 9 RI POINTS TO LOCAL FRAME 
SP EQU 10 R10 IS THE STACK POINTER 
re eee ESE ES EE SEE SESE ESE SES SEP EP SESE SERS REET PARE E REL ESE RE REESE LS 
* -- PROCEDURE DESCRIPTOR -- * 
ree eee ERE RERP ERLE SESE EEE SESE LEEPER EE EEE ERR ER ERE RE RES EAR EAE REESE SY 
| PSEG 
(6)~- Proced EQU $ 
0) DATA =->nnnn NEGATIVE OF ARG SIZE (BYTES) 
TORO PEPE SES EAE SCE SES ESE SEALE ESTELLE ECE ERE SERA REE ESE EE 
* -- USER CODE -- * 
RREKEKRKRKRKRKKRKRKRRKRKRRRKKRKKRRKKRKKRRKKRKRKRKKRKRKKKRRKKKRRKKREKEKRKRRKRREE 
eer Sample references to arguments 
MOV *LF,@<ga> GET 1ST ARGUMENT 
@0)\——> jwov @2(LF) ,@<ga> GET 2ND ARGUMENT 
cae NOTE: Optimized routines may 
jess not call other routines. 


Lecce eee eee ERE RE RE RERAEEE LER ERE SEE EER AREER ERE ERE REEL EEE LES SS 


“ -~- PROCEDURE TERMINATION CODE -- as 
KHKKKEKEKEEKEEREKREKEREREREREEEEKREEREKEKREKEKRKAEKREKKEKKKKEKKKR KEE 
RTWP RETURN TO CALLER 
END 


C.6 TEMPLATE FOR AN OPTIMIZED FUNCTION 


The following template specifies the format of an optimized function. 
An optimized function may only return a single word result (a standard 
function may return a one, two, or four word result). The restrictions 
which apply to an optimized procedure also apply to an optimized 
function. 3 


“* 
Ps ewe 
¢ pte 
a a ,- 
hp } 


Lo ee 
as acd 
Sse 








See ee a a se 





(.)}—____> IDT “’functi’ : FOR OPTIMIZED FUNCTION 
KKKAEKKEKEKKEKKREEKEEKE KEKE KKEEKEEEKEEKEEKEEKEEEEKEEEEEKEKRERKRKEKRKEEESE 
* -~- MODULES DEFINED -- * 
KEKKKEKKKEKRKKRKEEEEKKEEEEEKEKKKEEKEEEREKEKEKEREREEEKRKKKEKRRKKKEKEE 


DEF functi 
KREKEKKKRKKKKKKERKEKKKEKKEEEKEKEEKEKERKKRREKKEKRKRKKKREKEKKKEKRKEKKEKEKKE SE 


* -- EXTERNAL REFERENCES -- * | 
KKEKKEKKREKKEKEKKRKKEKEKKK KKK KKK KKK KKK KKK | 


REF EXITSO 
KEEKEEKRKEEKEKKREEKRKKKKEKRKKKKEEKKEEKEKEEEKREEKEEEKKRKRKKKEKKEKK KEKE 








* -- REGISTERS -- * 
KEKKKEKEKEKEEEEKEEEREKEEEKERKEKEREEEEKEREKEEEKKEREKKERRKKRKRKKRES 
PR EQU 7 R7 POINTS TO PROCESS RECORD 
(4) CODE EQU- 8 R8 POINTS TO CODE BASE 
LF EQU 9 RY POINTS TO LOCAL FRAME 
SP EQU 10 R10 IS THE STACK POINTER 
KEKKEKKKKEEKEKEKEEKEEKEEKEKEKEKEKEEEREEEEKEKEEEKEKEKEEKEREEKEEEE 
* -- PROCEDURE DESCRIPTOR -- * 
KKKKKKKKMKKKEKKKEKKEKKKEKEKREEKEKEEKEEKEEEEKEEEEEREEEEKEREKKEEE 
PSEG 
(6) functi EQU $ 
DATA ->nnnn NEGATIVE OF ARG SIZE (BYTES) 
KKEKKKKEKKEKEEKKKEEKEEKEKKEKEEKEKEKEEKEEKEEEEKKEKREREEEKKKEKKKEESE 
* -- USER CODE -- * 
KEKKEKEKEREEEKEEKKEEEKEKEEKEKKKEEEKEEKEREEEREEKEEEERRKEKKEEEEREKEES 
sou | Sample references to arguments 
20) MOV *LF,@<ga> GET 1ST ARGUMENT 
20 MOV @2(LF) ,@<ga> GET 2ND ARGUMENT 
ees NOTE: Optimized routines may 


not call other routines. 


KKEEKKEKKEKEKEKKEKEKEKKEEKEKKEEEEKEEKEEEKEKKEKEKEKEEKEKEKKKKEKRKKEKKRRKES 


_* -- PROCEDURE TERMINATION CODE -- * 
KKEEKKKKEKKEKEKEKEKEKKEKKEEKEREKKKEEEKEREEKEREKEEEEKEKREEKKEKKREEE 
MOV @result,*SP+ 
(29) " ) BL @EXITSO | EXIT OPTIMIZED FUNCTION 


END 


eee Es ee eee ee 





.7 ae 
Cc NOTES oe 


1) An IDT statement which gives the module its name. 


2) Each module must contain a DEF directive, which must be the 
| Same six letter (or less) label that defines the beginning of 
the descriptor. 


3) Any external modules (user or executive) that are used by the 
process must be REFed as being external. 


4. Register equates for the four Rx defined registers: (PR) 
Process record pointer, (CODE) code base, (LF) local frame 
pointer, and (SP) stack pointer. 


5) A PSEG statement is needed to declare the beginning of the 
program code. | 


6) A label which defines the beginning of the descriptor section 
of the routine. This label should be set to the first six 
characters of the routine name unless the process is at the 
outermost level and is therefore a system. The main routine or 
system should be labelled "SYSTMS$". 


7) An assembler defined constant which specifies the number of 
bytes from the beginning of the descriptor section to the .-. 
beginning of the prologue section (i.e., the offset to the | 
first executable statement). 


X, 
eo 


8) An assembler defined constant which specifies the number of 
bytes from the beginning of the descriptor section to _ the 
beginning of the epilogue section (i.e., the offset to the 
termination code). 


9) A Zero value constant necessary for proper linkage. 


10) The size in bytes of the parameters that have been passed _ to 
this process. 


11) The size in bytes of the local storage required by this 
Procedure/ function. 


12) The! total stackframe size in bytes. This includes the size of 
any! local variables plus the passed parameters. 


13) The lexical level is an integer which represents the level of 
nesting at which this process iS operating. The outermost 
level (the SYSTEM level) is designated as level QO. Any 
Processes that are started by the SYSTEM level would be level 
l1 and any started by these would be level 2, etc. Note that 
lexical level nesting conventions must be STRICTLY obeyed. 




















14) Process priority is an integer greater than 0 and less’ than. 


15) 


16) 


17) 


18) 


19) 
20) 
21) 
22) 
23) 
24) 
25) 


26) 


32767. Priorities 1 through 15 correspond to interrupt level 
priorities which are allocatable to a ouser”s process. The 
lower the numerical value, the higher the process” urgenc~. 


The stack size indicates the amount of memory in words that is 
to be allocated to this process for stack frames’ and 
workspaces of routines called within this process. The actual 
numerical value needed by any specific process will vary 
according to what routines the process calls. To start the 
process will generally take around 150 words in addition any 
other requirements that the process might have. 


The heap size indicates the amount of memory in words that the 
process requires for dynamically allocated variables’ and 
stacks of nested processes. If the heap size is set to zero, 
the process takes any heap it needs from its parent’s' heap. 
However, a process that has no heap specifically allocated to 
it (when it is started), will not be able to call another 
process. The implication of this is that a process must have 
enough heap for itself and all of its lexical descendants. The 
system level process should have enough heap for all processes 
and is often specified as zero to indicate that the system 
level process can take all available memory as its heap. 


The user may define any number of data words which may be used 
as constants by the process. 


A label which defines the first executable statement of the 
routine. | 


Process prologue code required to start the process. 
Sample references to arguments passed by caller. 
Sample call to another routine. 

Sample call to another function. 


A label which defines the beginning of the epilogue code. 


Epilogue code required to terminate a process in RX . 


Epilogue code required to terminate a standard procedure. 


Epilogue code required to terminate a standard function. The 
value of “n* is the number of words that the function result 
occupies (e.g., for an integer, “n* would be 1; for a real 
number, 2); valid values are. 1, 2, and 4. The data word 
following the branch is used by the exit handler to indicate 
the byte displacement into the local storage of the result to 


be returned. 








27) Epilogue code required to terminate an optimized procedure. 
28) Epilogue code required to terminate an optimized function. 


29) End statement required to terminate a source module. 


3 














D.1l 


APPENDIX D 


Rx SIZE BREAKDOWN 


FUNCTIONAL UNIT (MODULE NAMES) SIZE IN DECIMAL BYTES 


1) Target configuration description 


2) 
3) 
4) 


>) 


6) 


7) 


(CONFIG) fie eels. tatty eee ae ah teria det allg tie: Geile te wahoo lena devi sear ete aGUe: ae eee oe 
Rx Minimum. @eeooeseoeeeeees#se7?e?e@ of @®eesee7ueoese4eosgeoPseaseeeseseesteeeeest tees e 8 3034 
Clock Routines. eeoeeee*ese?8eeesee@ede?eseseeeemeee1eseee7e*@eeeeeeeestee?#t??teee 720 


Channel Routines (INIT, ALLOC, DISPOSE, SEND, WAIT 
RECEIVE, ACKNOWLEDGE) :é.@ os: 6:63 6 6's Hw OWS S00 0 wre wie ees 3 O44 


RX with ClOCK 634.068 06s cede st Hehe Seen Seen eee! +..34 
RX with Channe [6 sek 6 68-6 6.00666 6 Sw See ee sw 4140. + 34 


Rx with CEVErYthinG vieciscsce icin cewsseweeewes 410 + 34 


¢é 


(CONFIG) 
(CONFIG) 


(CONFIG) 














me Ll oe: 








APPENDIX E 


RXDEMO: ASSEMBLER LISTING AND LINK MAP 


The assembler listing and link map that follows is provided for’ use 
with the AMPL Debugger Walkthrough (Section VIII). 





‘DEMO 


002 
003 
004 
005 
006 
007 
008 
009 
010 
011 
O12 
013 
014 
O15 
016 
017 
018 
019 
020 
O21 
022 
023 
024 
025 
026 
027 
028 
029 
130 
I31 
J32 
)33 
134 


+ Fe + Fe FH HF HF HF HF HF OF HF HF HF HF HF HF HF HF HF HF HF HF HH F 


KkeAKKKKKKKKKKKEKKKKKKKRKRKKRKKKRKRKRKKRKRKRKRKKKKRKKKRKEKRR KKK KKK 


SDSMAC 3.3.0 79.312 
(DEMO -- DEMONSTRATION PROGRAM FOR RX 2.0 


IDT ~*RXDEMO~ 


10:05:30 THURSDAY, MAY 07, 1981. 


DEF RXDEMO 


DEF SYSTMS 
kKkkeeKkeKKRKKKKKKKRKRKRKRKRKRKKRKRKKRKRKKKKRKRKKRARKKKKRKKRKKRKRKKRKRKRKRRR RRR 


RXDEMO: RX 2.0 DEMONSTRATION 


PURPOSE: THIS PROGRAM DEMONSTRATES THE USE OF THE 


CALLS : 


NOTES : 


RX 2.0 REAL TIME EXECUTIVE TO IMPLEMENT 
A PRODUCER / CONSUMER PAIR OF PROCESSES. 


TWO PROCESSES ARE STARTED, “PRODUC” AND 
“CONSUM”. “PRODUC” AUTO-BAUDS THE USER 
TERMINAL AND ALLOCATES CHANNEL 1. IT THEN 
SENDS THE BAUD RATE OF THE TERMINAL TO THE 
CONSUMER OVER THE CHANNEL. IT THEN READS 
CHARACTERS FROM THE TERMINAL AND SEND THEM 


TO THE CONSUMER. THE CONSUMER PROCESS 


PRINTS OUT MESSAGES ABOUT THE CHARACTERS 

IT HAS BEEN SENT. WHEN THE PRODUCER READS 
AND SENDS A *2Z*, THE PRODUCER TERMINATES. 
WHEN THE CONSUMER RECEIVES A “2%, IT TERMI- 
NATES. 


PRODUC, CONSUM 


TERMINAL I/O IS DONE THROUGH A SET OF FOUR 
SIMPLE WAIT LOOP DRIVEN I/O ROUTINES. THESE 
CANNOT BE USED IN AN INTERRUPT ENVIRONMENT; 
FOR SUCH PURPOSES, THE “DEVICE INDEPENDENT 
FILE I/0° COMPONENT PACKAGE IS AVAILABLE. 
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* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 


me 
ea tN 
oer ire 
ge ate 























_~ °XDEMO 


0036 
0037 
0038 
0039 
0040 
0041 
0042 
0043 
0044 
0045 
0046 
0047 
0048 
0049 
0050 
0051 
0052 
0053 
0054 
0055 
0056 
0057 
0058 
0059 


~ 0060 
0061 


0062 


0063 
0064 
0065 
0066 
0067 
0068 
0069 
0070 
0071 
0072 
0073 


0000 


0000 
0002 
0004 
0006 
0008 
OO0A 
000C 
O00E 
0010 


SDSMAC 3.3.0 79.312 
xXDEMO -- DEMONSTRATION PROGRAM FOR RX 2.0 


0007 
0008 
0009 
000A 


0000° 
0000° 
0012 
0032 
0000 
0000 
0000 
0001 
0100 
0100 
0000 


* 


10:05:30 THURSDAY, MAY 07, 


1981 


PAGE 0003 
HK KKK KEI KEKE KK KEKE KEKE ERE KERR KEEEEEKREEEREKEEREKKERKKES 


-- EXTERNAL REFERENCES -- 
HKKKKKKKKKKEKE KEKE KEKE KEE EKER KEE KK KEKE EREKREREKEEKEEEKRES 


* 


REF CALLS 7 7 

REF SS$PRCS 

REF ESPRCS 

REF EXITSP 

REF PRODUC 

REF CONSUM 
KEKKKEEKKEEKKEREKREREEKEEKEEEEKEKEKEREKEREREEKEEEREKERERKEERSE 
* -- REGISTERS -- * 
REKEKKEKREKEKEKEKEKERKKEKEKEKEKKKERKEEKKKEKEKKKKEKEKKKKRKKEKEKKEKEK 
PR EQU 7 REGISTER 7 POINTS TO PROCESS RECORD 
CODE EQU 8 REGISTER 8 POINTS TO CODE BASE 
LF EQU 9 REGISTER 9 POINTS TO LOCAL FRAME 
SP EQU 10 - REGISTER 10 IS STACK POINTER 
* 


KREEKKEKEKKEKKEKKEKKERKKEEEKERERKEEKEKERKEKKEEEKKEKKEEKKERKKKRKEKEK 


* 


-- PROCESS DESCRIPTOR 


x 


KREKKKKKEKKEEKEKEKEEKRKEEKKEKEKEEKKEKEEKKRKEKKRKKKKKRERKKKEKEKKRRKKKKE 


SYSTMS 
RXDEMO 


FRMS IZ 


LEXLVL 


PRIORI 
STKSIZ 
HPSIZE 


PSEG 
EQU 
EQU 
DATA 
DATA 


$ 


$ 
PROLOG-RXDEMO 
EP ITLOG-RXDEMO 


DATA 0 


DATA 
DATA 
DATA 
DATA 
DATA 
DATA 


>0000 
>0000 
>0001 
>0100 
>0100 
>0000 


REQUIRED IN MAIN PROCESS 
NAME OF MODULE 

OFFSET TO FIRST STATEMENT 
OFFSET TO TERMINATION CODE 
ZERO FOR PROCESSES 

SIZE OF ARGUMENTS (BYTES) 
TOTAL FRAME SIZE (BYTES) 
LEXICAL LEVEL 

PROCESS PRIORITY 

PROCESS STACKSIZE (WORDS) 
PROCESS HEAPSIZE (WORDS) 


KRAEEKKEKKEEKKEEKKEEKKERKEEKKEEEKEKEKEEEKERKEEKEKEKEKKEKRREKKRERKKEEE 


-- USER DATA -- 
REKEKEKKKEKEEKEEEKKEKEKREEKEEKEKEKEREREREEEREKEEKKERKKKKREKRKKRKE 


* 


* 


* NONE 


* 


* 








2X DEMO 


0075 
0076 
0077 
0078 
0079 


0080 
0081 
0082 
0083 
0084 
0085 
0086 
0087 
0088 
0089 
0090 
0091 
0092 
0093 
0094 
0095 
0096 
0097 
0098 


0099 


0012 


0014 


0016 


0018 
OO1A 
001C 
OO1E 
0020 
0022 
0024 
0026 
0028 


002A 0026° 


002C 
002E 
0030 


0032 
0034 
0036 
0038 


SDSMAC 3.3.0 79.312 
RXDEMO -- DEMONSTRATION PROGRAM FOR RX 2.0 


10:05:30 THURSDAY, MAY 07, 1981. 


TRE SERRE E SESE EEE ERE RE ESLER EEE REESE EEE EEE ERR ERE EEE E SESS ES SE SE 


™ -- PROCESS START CODE -- " 
KHKKKK KKK EERE REREREKEEREEKKRRKKKRKKKKRKRKRKRKKE KKK KKK KK KEE 


0012° PROLOG EQU S$ 


CEA8 
0008 
CEA8 
000A 
CEA8 
000C 
CEA8 
O00E 
CEA8 
0010 
0000 
0000 


0000 


002A 


0000 


00327 


CEA8 
QO00A 


002E” 


0000 


003A 0460 


003Cc 


(0 ERRORS, 


0000 


MOV @FRMSIZ-RXDEMO (CODE) ,*SP+ PUSH FRAME SIZE, BYTES 


MOV @LEXLVL-RXDEMO(CODE) ,*SP+ PUSH LEXICAL LEVEL 


MOV @PRIORI-RXDEMO(CODE) , *SP+ PUSH PRIORITY 


MOV @STKSIZ-RXDEMO(CODE) ,*SP+ PUSH STACKSIZE, WORDS 


MOV @HPSIZE-RXDEMO(CODE) ,*SP+ PUSH HEAPSIZE, WORDS 


DATA CALLS,SSPRCS START THIS PROCESS 


ree eee eeeREREEREaRERE REE RERE SESSA ERE RESEERER ESSE SAS EES SESE RSA ERE ES | 
* -- USER CODE -- * 
te eee eee eeeeeeeeeeEER ERE SES ECE SESS EEE EEE EEE ESE EES EEE SE SAE SS 
* 


DATA CALLS, PRODUC START PRODUCER 


DATA CALLS$ ,CONSUM START CONSUMER 


*& 
RREKKKKKKKKKKKKKKKKKKRKKKKKKKRKRKRKKRKKRKKKKKKKKKKRRKKRKRKRKEKKRKK KKK 
* -- PROCESS TERMINATION CODE -- * 
ree eee eEEREEe EERE REESE S ES ESE REESE SEES SAE SERRE ESE SEES ESTER ERSTE SERS SE? 
EPILOG EQU $ 

MOV @LEXLVL-RXDEMO(CODE),*SP+ PUSH LEXICAL LEVEL 


DATA CALL$,ESPRCS TERMINATE THIS PRCS 


‘B @EXITSP EXIT 


END 


NO WARNINGS 


PAGE 0004 ©” 
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PRODUC 

-~ PRODUC --— PRODUCER PROCESS FOR DEMONSTRATION PAGE 7 
0002 IDT “PRODUC” 
0003 KAKI KERIKERI EERE RE REIKI REE REEEREEEREREREEEEEEEEEEES 
0004 * 
0005 * PRODUC: THE PRODUCER PROCESS | 
0006 * | 4 
0007 * PURPOSE: THIS PROCESS FIRST CALLS TISSET TO FIND THE 
0008 * BAUD RATE OF THE USER TERMINAL, AND THEN 
0009 * ALLOCATES CHANNEL 1. THE BAUD RATE FLAG FROM 
0010 * TISSET IS SENT TO THE CONSUMER PROCESS OVER 
001l * THE CHANNEL (THE CONSUMER NEEDS TO KNOW THE 
0012 * BAUD RATE OF THE TERMINAL SO THAT IT CAN ALSO 
0013 * PERFORM I/O). 
0014 * 
0015 * . THEN PRODUCER THEN READS CHARACTERS FROM THE 
0016 * TERMINAL AND SENDS THEM TO THE CONSUMER OVER 4% 
0017 * THE CHANNEL. WHEN THE PRODUCER RECEIVES A a 
0018 * “2°, IT SENDS THE MESSAGE, WAITS FOR ACKNOW- * 
0019 * LEDGEMENT, AND.TERMINATES. THE CONSUMER WILL % 
0020 * ALSO TERMINATE WHEN IT RECEIVES A “Z2”*. : 
0021 * 
net _* CALLS: TISSET, TISCIN, TISCOT, TISMSG : 
00 * 
0024 KKKEKKEEKEKKEKEKKEKEKKKEREKEKREEEEEREKEKEREKEEEEKEKEEEEKKKEKREK 
0025 DEF PRODUC | 
0026 HKEKEKKKEKKEEKEKEEKKEEKKEEEEEKREEEEKEEEEEEEKEKEREKEREKEEEEEEKEEK 
0027 * -- EXTERNAL REFERENCES -- * 
0028 KKEKEKKEEKEKEKEKEKEREKEEEKEKEKEEEEEEKEEKEKEEEEKEKEKEKEKEKREKEE 
0029 REF CALLS CALL SYMBOL 
0030 REF SS$PRCS START PROCESS 
0031 REF ESPRCS END PROCESS 
0032 REF EXITSP EXIT 
0033 REF CSINIT ALLOCATE A CHANNEL 
0034 REF CSTERM # FREE A CHANNEL 
0035 REF CSALLO ALLOCATE A MESSAGE BUFFER 
0036 REF CSSEND SEND A MESSAGE 
0037 REF CSWAIT WAIT FOR ACKNOWLEDGEMENT 
0038 REF TISSET SET BAUD RATE 
0039 REF TISCIN READ CHARACTER 
0040 REF TISCOT WRITE CHARACTER 
0041 REF TISMSG WRITE STRING 


wat ene Ee ee ment ec te coe 


>RODUC 


0043 
0044 
0045 
0046 
0047 
0048 
0049 
0050 
0051 
0052 
0053 
0054 
0055 
0056 
0057 
0058 
0059 
0060 
0061 
0062 
0063 
0064 
0065 
0066 
0067 
0068 
0069 
0070 
0071 
0072 
0073 
0074 
0075 
0076 
0077 
0078 
0079 
0080 
0081 
0082 
0083 
0084 
9085 


0000 


0000 
0002 
0004 


0000 


0000 
0002 


0000 


0000 
0002 
0004 
0006 
0008 
000A 
000cC 
O00E 
0010 


SDSMAC 3.3.0 79.312 
»RODUC -- PRODUCER PROCESS FOR DEMONSTRATION 


0001 


0002. 


0007 
0008 
0009 
OO0A 


0006 


0004 


0000° 


OOA4 
O1BE 


0000 


0000 
0006 
0001 
0100 
0100 
0000 
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HKREAKKKEKKERAKEKREKEEKEEEREEEEEREKEEEEEEEEEEKREEKREKEKREREEKEEEKE 


* -- REGISTERS -- * 
KREKKKEKKKEKKAKKKKKKRKKKKK KKK KKKKRKRRKREKRKKRKRKRKRKAEEKEE 


* MP EQuU l POINTER TO MESSAGE BUFFER 
TEMP EQU 2 USED TO CALCULATE ADDRESS OF VARIABLES 
*& . 
PR EQU 7 REGISTER 7 POINTS TO PROCESS RECORD 
CODE EQU 8 REGISTER 8 POINTS TO CODE BASE 
LF EQU 9 REGISTER 9 POINTS TO LOCAL FRAME 
SP EQU 10 REGISTER 10 IS STACK POINTER 


HRHEREEKKEEEEKEEKEKRKEEKRKEKEEKREREREKERKEKRRERKKKEKKKKRKKKRKKKKKKKREAE 


“i ~~ MAPPING FOR LOCAL FRAME --~- = 
HKKARKKEKEKERKRKEREKKKEKKKKRKEKRKKKKKKKRAEKKEKREKRKRKKKRKKKKRERKKRKKKE 


DORG 0 OFFSET FROM LF (R9) . 
*& 
BAUD BSS 2 
CHNLID BSS 2 
MSGBUF BSS 2 
LFLEN EQU $ 
* 


BAUD RATE FLAG FROM TISSET 
CHANNEL ID (PTR TO CHANNEL) 
POINTER TO MESSAGE BUFFER 


RARER RREKRREEKEREREREEERERERRREKRREKEEEREERERERRERERRERRERAE 


id ~~ MAPPING FOR MESSAGE BUFFER -- ig 
RKKKEKREREKREERREEEKREKEEREARKERERKEERERERKEAKRAERKEKRKEKARKRKKEKKERKKREKRE 


DORG 0 OFFSET FROM MSGBUF 
* 
CSLOT BSS 2 
BSLOT BSS 2 
MBLEN EQU §$ 
*& 


ONE WORD FOR BAUD RATE FLAG 


RARAEREREKERERERAEREEKEEEEKEKEEKEERERERRRERERREEEEKEKRERRKREKKRKEEE 


* -—- PROCESS DESCRIPTOR -- * 
rERPREREEESRALES SELES ESE SEE ESTES TEETER TEE TEE ET EEE ET ETE ET TET ES EEE ET: 
PSEG 
PRODUC EQU §$ 
DATA PROLOG-PRODUC OFFSET TO FIRST STATEMENT 
DATA EPILOG—PRODUC OFFSET TO TERMINATION CODE 
DATA 0 ZERO FOR PROCESSES 
DATA >0000 SIZE OF ARGUMENTS (BYTES) 
FRMSIZ DATA LFLEN TOTAL FRAME SIZE (BYTES) 
LEXLVL DATA >0001 LEXICAL LEVEL 
PRIORI DATA >0100 PROCESS PRIORITY 
STKSIZ DATA >0100 PROCESS STACKSIZE (WORDS) 
HPSIZE DATA >0000 PROCESS HEAPSIZE (WORDS) 





PAGE 0003" 


LOW ORDER BYTE IS ONE CHARACTER MESSAGE ~ 














{ 


2RODUC 


0087 
0088 
0089 
0090 
0091 
0092 
0093 
0094 


0095 


0096 
0097 
0098 
0099 
0100 


0101 
0102 


0103 
0104 
0105 
0106 
0107 
0108 
0109 
0110 
0111 
0112 
0113 
0114 
0115 


0116 
0117 


0118 
0119 
0120 
0121 


0122 


0012 
0014 
0016 
0018 


OO1A 
001B 
001C 
001D 
0039 
003A 
003B 
003C 


003D 
004C 


004D 
0072 


0073 
0086 
0087 
0088 
0089 
009D 
009E 
0O09F 
00A0 


OOAl 
O0A2 
00A3 
00A4 
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0012 
0001 
0014 
0004 
0016 
0080 
0018 
OO5A 


OOlA 
OD 
OA 
OA 
52 
OD 
OA 
OA 
00 


003D 
00 


004D 
50 
00 


0073 
50 
OD 
OA 
OA 
45 
OD 
OA 
OA 
00 


OOAl 


OA 
00 





| 
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HHRKKKKKKKKEKKKEKKEKEKEEKRKEKEEKEEREEEREREEEEEREREEEEEEEREREEEEEE 


* -- USER DATA -- aw 
Fee eee Ee eee eT A Lee ee eee en ae ee ee eT 
CHNAME EQU $-PRODUC | 
DATA 1 USE CHANNEL 1 
MSGLEN EQU $-—PRODUC 
DATA MBLEN LENGTH OF MESSAGE BUFFER 
PORTO1 EQU $-PRODUC 
DATA >0080 CRU BASE OF PORT NUMBER l 
Z EQU $-PRODUC 
DATA >5A Z IN ASCII 
Fe | 
HELLO EQU $—PRODUC 
BYTE >0D,>0A,>0A- -  <€CR><LF><LF> 
TEXT “RX 2.0 DEMONSTRATION PROGRAM* 
BYTE >0D,>0A,>0A <CR><LF><LF> 
BYTE 0 <NUL> TO TERMINATE STRING 
* 
SENDMS EQU $=—PRODUC 
TEXT “PRODUCER SENDS ” 
BYTE 0 
* 
ACKMSG EQU $—PRODUC P 
TEXT “PRODUCER RECEIVES ACKNOWLEDGEMENT OF 
BYTE 0 
* 
GOODBY EQU S$=—PRODUC 
TEXT “PRODUCER TERMINATES” 
BYTE >0D,>0A,>0A <CR><LF><LF> 
TEXT “END OF DEMONSTRATION” 
BYTE >0D,>0A,>0A <CR><LF><LF> 
BYTE 0 <NUL> TO TERMINATE STRING 
* 
CRLF EQU $+PRODUC 
BYTE >0D,>0A,>00 <CR><LF><NUL> 
EVEN CODE MUST START ON WORD BNDRY 


eee ee ern eer erie oe ee reer os 





PRODUC 


0124 
0125 
0126 
0127 
0128 
0129 
0130 
0131 
0132 
0133 


0134 
0135 


0136 


0137 


0138 
0139 


0140 
0141 


0142 
0143 
0144 
0145 


0146 


0147 
0148 


0149 
0150 


0151 
0152 
0153 
0154 


0155 
0156 


0157 
0158 


O0A4 
OOA6 
00A8 
OOAA 
OOAC 
OOAE 
00B0 
00B2 
00B4 
00B6 
00B8 
OOBA 


00BC 
0OBE 
00c0 
00C2 
00c4 
00Cc6 
00c8 
OOCA 


00cCc 
00CE 
00D0 
00D2 


00D4 


00D6 
00D8 
OODA 
00pc 
0ODE 


0OE0 
00E2 
00E4 
O0E6 
00E8 
OOEA 
0OEC 
O0EE 
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CEA8 
0008 
CEA8 
000A 
CEA8 
000C 


CEAS8 . 


O00E 
CEA8 
0010 
0000 
0000 


CEA8. 
0016 
c089 
0222 
0000 
CE82 


00B8° 


0000 


CEA8 
0016 
CEA9 
0000 
c088 
0222 
OO1A 
CE82 


00c8° 


0000 


CEA8 
0012 
c089 
0222 
0002 
CE82 


00DC” 


0000 
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HHKAKKKAKKKAKEREKRREAKERAEERAERAKKRKAKAEKKEKRKKRKKRKRKKKKAKKRKRRRERKE 


* 


-- PROCESS START CODE -- * 


PERE LELEL ELSES EEL EET ETE ST ELE LEE EE EEE ESET EEL EEL ESET ELE REET ETE SE 
00A4“ PROLOG EQU 


_ MOV 
MOV 
MOV 
MOV 
MOV 


DATA 


$ ; 
@FRMSIZ-PRODUC (CODE) ,*SP+ PUSH FRAME SIZE, BYTES 


-@LEXLVL-PRODUC (CODE) ,*SP+ PUSH LEXICAL LEVEL 


@PRIORI-PRODUC (CODE).,*SP+ PUSH PRIORITY 


@STKSIZ—PRODUC (CODE) , *SP+ PUSH STACKSIZE, WORDS 
@HPSIZE-PRODUC (CODE) ,*SP+ PUSH HEAPSIZE, WORDS 


CALLS ,S$PRCS START THIS PROCESS 


kReRKRKKRKKKKKKKRKRKKRKR KKK KKK KKK KKKKRRKEKKERERRKERRKKRKEKE 


* SET BAUD RATE FLAG “BAUD~ id 
KKKKKKRKEKERKEKAEKEKERERKERREKERKREEKKRAEEKEKKKEKKRRKRERKKEKKESE 


MOV 


MOV 
AI 


MOV > 
DATA 


@PORTO1 (CODE) , *SP+ PUSH CRU BASE OF PORT l 


LF, TEMP PUSH PTR TO BAUD RATE FLAG 
TEMP , BAUD : (LOCAL FRAME+OFFSET) 
TEMP,*SP+ _ : | | 

CALLS , TISSET AUTO-BAUD THE TERMINAL 


kkkkKKKKKKKRKRKKKKRKKKKKKKKKRR KKK KKRKKRRAKKKK KKK KARE 


* WRITE “RX 


2.0 DEMONSTRATION PROGRAM#0D#0A#0AF0A~ id 


reece ee eEEEAEEE RRR EEE RRR E EE EER AREER EERE RESELL ERE EEE EERE ETE SE SE 


MOV 
MOV 


MOV 
AI 
MOV 
DATA 


@PORTO1 (CODE) ,*SP+ PUSH CRU BASE OF PORT 1 


@BAUD (LF) , *SP+ PUSH BAUD RATE FLAG 


CODE , TEMP PUSH PTR TO MESSAGE 
TEMP , HELLO ¢ (CODE BASE+OFFSET) © 
TEMP , *SP+ ° 

CALLS , TISMSG WRITE THE STRING 


ree eeeeEeESEEE REE SESE SERRE LER ESE LES ELE ESE RE SEL ERE LE LE LES EEE SS 


* ALLOCATE CHANNEL “CHNAME”~, PUT RESULT IN “CHNLID* . 
KHEKKKKEKKEKKKEKEEKERE KEKE ERE EKER EKREREREREERERKKERKERAKKES 


MOV 


MOV 
AI 


MOV 
DATA 


@CHNAME (CODE) , *SP+ PUSH NAME OF CHANNEL (1) 


LF, TEMP PUSH PTR TO CHANNEL ID 
TEMP , CHNLID : (LOCAL FRAME+OFFSET) 
TEMP, *SP+ bd 
CALLS ,CSINIT ALLOCATE THE CHANNEL 


ay 


PAGE 000. '*” 
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PRODUC -- PRODUCER PROCESS FOR DEMONSTRATION PAGE 000 
0160 LL ELERAAES ARS ASAE TE ee eee Oe ee eh ee ene ye eee ee 
0161 * ALLOCATE MESSAGE BUFFER “MSGBUF” 
0162 Beg eee ee ee eee eee ea aes 
0163 OOFO CEA8& MOV @MSGLEN(CODE) ,*SP+ PUSH LENGTH OF BUFFER 
OOF2 0014 7 | 
0164 O0OF4 c089 MOV. LF, TEMP PUSH PTR TO MSGBUF ! 
0165 OOF6 0222 AI TEMP , MSGBUF : (LOCAL FRAME+OFFSET) 
OOF8 0004 
0166 OOFA CE82 MOV TEMP, *SP+ : “7 
0167 OOFC O0EC’ DATA CALLS ,CSALLO 
OOFE 0000 
0168 KKEKEEKEEKKEKEKEREKAEKKEEKEEEEKEKREREKREEKEEEKEEKEEEKEEREEEEEKEKER 
0169 * @(BSLOT+MSGBUF) := “BAUD” | 
0170 KEKREKKEKEKEKEEEEKEKEKEEREKEKEKEKEEEEEKEKEEEEKEKEEEEEEEKEEEEEE 
0171 0100 c069 MOV @MSGBUF (LF) ,MP MOVE VALUE TO REGISTER MP 
0102 0004 
0172 0104 c869 MOV @BAUD(LF),@BSLOT(MP) PUT BAUD RATE INTO MESSAGE 
0106 0000 ! 
0108 0002 
0173 KREKKEEKEKEEEEEKEEKEKEKEEKEKEKREEKEKKEERAKKKERERKEEKEEKKEEEEEKEEKEREKEEKEE 
0174 * UNTIL “CHAR” EQ °Z* READ CHARACTER “CHAR” | 
0175 KEKEKEKEEKEEKEEKEKEREKEEKRERKEREKEEEEEKEKEEEKEKEEEEEKKEKKAEKKEREE 
0176 010A CEA8 SENDLP MOV @PORTO1(CODE) ,*SP+ PUSH CRU BASE OF PORT 1 | 
010c 0016 | 
0177 O10E. cO081l MOV MP, TEMP PUSH PTR TO CHARACTER 
0178 0110 0222 AI TEMP ,CSLOT ¢ (MSG BUF PTRt+OFFSET) 
0112 0000 
0179 0114 CE82 MOV TEMP, *SP+ : 
0180 0116 OOFC’ DATA CALLS, TISCIN READ A CHARACTER | 
0118 0000 
0181 KEKEKKEKKEKEKEEEKEEEEKEEKKEEKEEEEEKEEEEEEEKEKEEKERKERKEEKKEKKEKEE 
0182 * SEND “MSGBUF” OVER “CHNLID” 
0183 KEKEKKKKKEKEKEKEEEREEEKEKEEEREKEKEKEKEEREKEEEKEKEEKEKEKEREREEE 
0184 011A CEAS MOV @CHNLID(LF) , *SP+ PUSH CHANNEL ID 
Ollc 0002 
0185 011E CE81 MOV MP,*SP+ PUSH MSG BUFFER PTR 
0186 0120 01167 DATA CALLS ,CSSEND SEND MESSAGE 
0122 0000 





?RODUC 
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2RODUC -~ PRODUCER PROCESS FOR DEMONSTRATION 
HAKKKCREREKREREREAREEEKRAREEAREREREAREKKKRKAKEKKERKKEKKEKEKKEKKKRRKEKKRER 


* WRITE “PRODUCER SENDS c” 
RARER ERERERERERR KEKE 


0188 
0189 
0190 
0191 


0192 


0193 
0194 


0195 
0196 


0197 
0198 


0199 
0200 
0201 


0202 
0203 


0204 


0205 
0206 


0207 
0208 


0209 
0210 
0211 
0212 
0213 


0124 
0126 
0128 
012A 
012c 
012E 
0130 
0132 
0134 
0136 


0138 
O13A 
013¢C 
O13E 
0140 
0142 
0144 
0146 


0148 
014A 
014C 
0O14E 
0150 
0152 
0154 
0156 
0158 
O15A 


015C 
015E 
0160 


CEA8 
0016 
CEA9 
0000 
C088 
0222 
003D 
CE82 
01207 
OODE~ 
*& 
CEA8 
0016 
CEA9 
0000 
CEA1 
0000 
01347 
0000 


CEA8 
0016 
CEA9 
0000 
co8s 
0222 
O0OAl1 
CE82 
0144° 
0136° - 


MOV 
MOV 


MOV 
AI 


MOV 
DATA 


MOV 


‘MOV 


MOV 


DATA 


MOV 


MOV 


MOV — 
AI 


MOV 
DATA 


@PORTO1 (CODE) ,*SP+ PUSH CRU BASE OF PORT l 


@BAUD (LF). , *SP+ 


CODE, TEMP 
TEMP , SENDMS 


TEMP , *SP+ 
CALLS , TISMSG 


@PORTO1 (CODE) , *SP+ 


@BAUD (LF) , *SP+ 


@CSLOT (MP) , *SP+ 


CALLS , TI$SCOT 


@PORTO1 (CODE) , *SP+ 
@BAUD (LF) , *SP+ 


CODE , TEMP 
TEMP , CRLF 


TEMP , *SP+ 
CALLS , TISMSG 


10:08:10 THURSDAY, MAY 07, 


1981. 


PUSH BAUD RATE FLAG 


PUSH PTR TO MESSAGE 
¢ (CODE BASE+OFFSET) 


WRITE THE STRING 


PUSH CRU BASE OF PORT l 


PUSH BAUD RATE FLAG 


PUSH THE CHARACTER 


WRITE THE CHARACTER 


PUSH CRU BASE OF PORT l 


PUSH BAUD RATE FLAG 


PUSH PTR TO MESSAGE 
: (CODE BASE+OFFSET) 


WRITE THE STRING 


& 


Leek eeeeREREREERERE EE LER EEE EEE ERE TEE EEE ETE EEE EEE EEE EEE ETT ST SS 


* 


WAIT FOR ACKNOWLEDGEMENT OF “MSGBUF” 


* 


RKREKRRRRRKRKRKRKRKARKRERRKRKRRKRKRKKKKRKRRKRKRKKRRKREKRKRKKRKKKRKRKRKRKEKRKRRKKREKRKRKREK 
MOV MP,*SP+ 


CE81 
0158” 
0000 


DATA 


CALLS ,CSWAIT 


E-10 


PUSH MSH BUFFER PTR 


WAIT FOR ACKNOWLEDGMENT 


PAGE 0007. 


( 


Cy 

















- - PRODUC 
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7 SDSMAC 3.3.0 79.312 ! 
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0215 KKEKKKEKKEEKEEKEEREKEKEKEKEKEEKEKEREEKEREEKEKEEKEEEKKEEKKKRKEEE 
0216 * WRITE “PRODUCER RECEIVES ACKNOWLEDGEMENT OF c” * 
0217 de de dee KKK KKK KEKE RER EERE REE EERE EERE 
0218 see - MOV @PORTO1 (CODE) ,*SP+ PUSH CRU BASE OF PORT 1 
1 
0219 0166 CEA MOV @BAUD(LF) , *SP+ PUSH BAUD RATE FLAG 
0168 0000 
0220 016A cO8s MOV CODE, TEMP PUSH PTR TO MESSAGE 
0221 016c 0222 AI TEMP , ACKMSG : (CODE BASE+OFFSET) 
016E 004D 
0222 0170 CE82 MOV’ TEMP, *SP+ : 
0223 0172 015k” DATA CALLS, TISMSG WRITE THE STRING 
0174 015AzA’ 
0224 | 
0225 i cece MOV @PORTO1 (CODE) ,*SP+ PUSH CRU BASE OF PORT 1 
0226 017A CEA9 ‘MOV @BAUD(LF) , *SP+ PUSH BAUD RATE FLAG 
017c 0000 
0227 017EF CEAL MOV @CSLOT(MP) , *SP+ PUSH THE CHARACTER 
0180 0000 | 
0228 0182 01727 DATA CALLS, TISCOT WRITE THE CHARACTER 
0184 01467 
0229 
— 0230 ep Soe MOV @PORTO1 (CODE) ,*SP+ PUSH CRU BASE OF PORT l 
-- 0231 018A CEA MOV @BAUD(LF) , *SP+ PUSH BAUD RATE FLAG 
018c 0000 
0232 018EF c088 MOV CODE, TEMP PUSH PTR TO MESSAGE 
0233 0190 0222 AI TEMP, CRLF : (CODE BASE+OFFSET) 
0192 OOA1 
0234 0194 CE82 MOV TEMP, *SP+ : 
0235 0196 01827 DATA CALLS , TISMSG WRITE THE STRING 
0198 01747 
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0237 ERR RRR ERE RIKER ERE R RR RRR ER RR ERE R ERE REE RRR REE RE 
0238 * END { UNTIL “CHAR’ EQ °27 | * 
0239 kReKkKKKKKKKKKKKRKRKR RK RRR KRHA KRKRRARRKERKRE 
0240 019A 8A21 Cc @CSLOT(MP) ,2(CODE) IS CHARACTER “2%? 
019c 0000 
019F 0018 | 
0241 O1A0 16B4 JNE SENDLP NO: LOOP 
0242 KkKRKEKKRKKRKRKKRKRRKKRKR KKK KEKE KKKKKRKRKRKKRRKRKKKRKRKRKRRRRKRKRRKRKRKEE 
0243 * FREE “CHNLID* (AUTOMATICALLY FREES “MSGBUF”) ud 
0244 | PTE RRR E EEE SESE EEE REESE ESTES ESTEE EERE EERE EEE EERE EEE EAE EES 
0245 01A2 CEA9 MOV @CHNLID(LF) , *SP+ PUSH CHANNEL ID 
01A4 0002 
0246 01A6 01967 DATA CALLS ,C$TERM FREE THE CHANNEL 
01A8 0000 
0247 Fee te a eee ee OE Te ane en eae eG 
0248 * WRITE “PRODUCER TERMINATES” 
0249 RERKKRKeKRRRRRRRRKRKKKKKKEKRRKRRKKRRKRKKKKKRKEKKERAKRK KKK RARER 
0250 O1AA CEA8 MOV @PORTO1(CODE) ,*SP+ PUSH CRU BASE OF PORT l 
Q01AcC 0016 
0251 O1AE CEA9 MOV @BAUD(LF) , *SP+ PUSH BAUD RATE FLAG 
01B0 0000 
0252 01B2 c088 MOV CODE, TEMP PUSH PTR TO MESSAGE 
0253 01B4 0222 AI TEMP , GOODBY ¢ (CODE BASE+OFFSET) 
01B6 0073 | 
0254 01B8 CE82 MOV TEMP, *SP+ : a 
0255 O1BA 01A6% DATA CALLS, TISMSG WRITE THE STRING 
| 01Bc 01987 | : | 
0256 RRKRKKRRKRRRKKRRRKRKRRKRKRKRKRKRKRKRKRKEKKRRRKKKRKRRKKRKEKRKRKKKERRKRKRRKRKRRKEKKRKKEKRKRKRKE SE 
0257 * -~- PROCESS TERMINATION CODE -- * 
0258 KREKREKRRKRKRRKRRRKRKRREKKRKRRRKRKRKRRKRKRKKRKRRKRKRKRKKRKRKRKRKRKKRKRRKRKKRKEKRKRKRKKRKEKKRER 
0259 O1BE” EPILOG EQU $ | 
0260 O1BE CEA8 MOV @LEXLVL-PRODUC(CODE) ,*SP+ PUSH LEXICAL LEVEL 
01cO OOOA 
0261 O0lc2 01BA” DATA CALLS,ESPRCS TERMINATE THIS PRCS 
01c4 0000 
0262 01¢c6 0460 B . @EXITSP EXIT 
01c8 0000 
0263 END 
NO ERRORS, NO WARNINGS 
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CONSUM -- CONSUMER PROCESS FOR DEMONSTRATION PAGE 000 








0002 IDT “CONSUM* 

0003 SAS ES ET Se eee T EASE SEA AAAs eee TAS eRe eRe AAS A ESR ee 
0004 * | 
0005 * CONSUM: THE CONSUMER PROCESS 

0006 ~ 

0007 - PURPOSE: THIS PROCESS FIRST ALLOCATES CHANNEL 1, AND 
0008 > THEN WAITS FOR A MESSAGE TO APPEAR ON THE 

0009 * CHANNEL. WHEN IT RECEIVES A MESSAGE, IT TAKES 
0010 = THE CHARACTER AND BAUD RATE FROM THE MESSAGE 
0011 bd AND PRINTS THE CHARACTER ON THE USR TERMINAL. 
0012 x WHEN THE CONSUMER RECEIVES A “2°, IT PRINTS 
0013 . THE CHARACTER AND TERMINATES. 

0014 * 

0015 * CALLS: TISCOT, TISMSG 

0016 . | | 
0017 KKKKKKKEKEKEKEKEKEKEEEKEKEKEEKEKEEKEKEEEREREKREKEKEEKEKEKKRKKKKKKK 
0018 DEF CONSUM 

0019 KHKEKKEKEKKEKEKKEKKEEEEKKEEEKEKKKEEKEEKEEEEKEKEEEKEREEEEREEKEKEEEEEREKRK 
0020 ~ : -- EXTERNAL REFERENCES -- 

0021 KEKKKKKEKKEEKEKEEKKEEKEEKEEEEEEEKEEKEEKEEREKEKEKERERKEREREREREREEKE 
0022 REF CALLS CALL SYMBOL 

0023 REF S$PRCS START PROCESS 

0024 REF ESPRCS END PROCESS 

0025 REF EXITSP EXIT 

0026 REF CSINIT ALLOCATE A CHANNEL 

0027 REF CSTERM FREE A CHANNEL 

0028 REF CS$RECE RECEIVE A MESSAGE 

0029 REF CSACKN ACKNOWLEDGE A MESSAGE 

0030 REF TISCOT WRITE CHARACTER 

0031 REF TISMSG WRITE STRING 

0032 KHKKKKKKKKKEKEKEKEKEKEKKKEKEKEEKEKEEEEEKEEEKEEEKEEEKEKKEKEKKKKKKKES 
0033 x -- REGISTERS -- 

0034 KEKKKKEKEKEKEKEEREKEKKEEKEREKREEEEKEEEKEKKEEREREEKEEEREKEKEKEKEKEE 
0035 OOO1 MP EQU il POINTER TO MESSAGE BUFFER 

0036 0002 TEMP EQU 2 USED TO CALCULATE ADDRESS OF VARIABLES 
0037 * 

0038 0007 PR EQU 7 REGISTER 7 POINTS TO PROCESS RECORD 
0039 0008 CODE EQU 8 REGISTER 8 POINTS TO CODE BASE 

0040 0009 LF EQU 9 REGISTER 9 POINTS TO LOCAL FRAME 

0041 OOOA SP EQU 1 REGISTER 10 IS STACK POINTER 
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ONSUM 


0043 
0044 
0045 
0046 
0047 
0048 
0049 
0050 
0051 
0052 
0053 
0054 
0055 
0056 
0057 
0058 
0059 
0060 
0061 
0062 
0063 
0064 
0065 
0066 
0067 
0068 
0069 
0070 
0071 
0072 
0073 
0074 


0000 


0000 
0002 


0000 


0000 
0002 


0000 


0000 
0002 
0004 
0006 
0008 
OO0A 
000C 
O00E 
0010 


SDSMAC 3.3.0 79.312 
ONSUM -- CONSUMER PROCESS FOR DEMONSTRATION 


0004 


0004 


0000° 


0046 
00E4 
0000 
0000 
0004 
0001 
0100 
0100 
0000 
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TREES ERP EPESRE ELE EL EE ERE EE EET ESE LEP EE TE TEL EET ETE REE EEE ERA EE EES SE 


* ~- MAPPING FOR LOCAL FRAME --- * 
KEKE KKK RAEKEEAKRREKEEKKRRKKERRKRKKRRRKKKRKREKRARRKESE 


DORG 0 OFFSET FROM LF (R9) 
J 
CHNLID BSS 2 
MSGBUF BSS 2 
LFLEN EQU $ 
# 


CHANNEL ID (PTR TO CHANNEL) 
POINTER TO MESSAGE BUFFER 


REKRKKKEEKKEREEKEKEREKEKKKREKKKKKKRRKRKKEKEKRKKKERKRKKRRKRKKEKKRKKKKKRKKK 


= -- MAPPING FOR MESSAGE BUFFER -- - 
KKKEKKKKKKKKKKKKKEKKKKKKKKKKKKKKRKREKKEKKEKKKKKKKKKAKKKRKKKKRKK KEE 


DORG 0 OFFSET FROM MSGBUF 
* 
CSLOT BSS 2 
BSLOT BSS 2 
MBLEN EQU. S$ 
# 


LOW ORDER BYTE IS ONE CHARACTER MESSAGE 
ONE WORD FOR BAUD RATE FLAG 


kkk KKK KR KKK 
* -- PROCESS DESCRIPTOR -- * 
Pe eeERESESESE SELLE LEE LE LES ESE EEE PPE EET TPE EET EET TST SPE T EES | 
PSEG 
CONSUM EQU S$ 
DATA PROLOG-CONSUM 
DATA EPILOG-CONSUM 


OFFSET TO FIRST STATEMENT 
OFFSET TO TERMINATION CODE 


DATA 0 ZERO FOR PROCESSES 

DATA >0000 SIZE OF ARGUMENTS (BYTES) 
FRMSIZ DATA LFLEN TOTAL FRAME SIZE (BYTES) 
LEXLVL DATA >0001 LEXICAL LEVEL 
PRIORI DATA >0100 PROCESS PRIORITY 


PROCESS STACKSIZE (WORDS) 
PROCESS HEAPSIZE (WORDS) 


STKSIZ DATA >0100 
HPSIZE DATA >0000 
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-CONSUM -- CONSUMER PROCESS FOR DEMONSTRATION PAGE 0004 | 


KKEKEKKEEKKEKEEEEKEKEKEEEEKREKEEKEEKKEKEKEEKEKEEEKKKEKKEEKKKEEEEE 
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0076 
0077 * -- USER DATA -- ae 
0078 KKKKKKKEKKKEKKEKEKKEEKKEKEREKEKEKEKEEEKEKKEEEKEKEEKEKEEEKEEEEEKEEEREKREE 
0079 * 
0080 0012 CHNAME EQU S-CONSUM 
0081 0012 0001 DATA 1 USE CHANNEL 1 
0082 * 
0083 0014 MSGLEN EQU $-CONSUM 
0084 0014 0004 DATA MBLEN LENGTH OF MESSAGE BUFFER 
0085 * 
0086 0016 PORTO] EQU $-CONSUM 
0087 0016 0080 DATA >0080 CRU BASE OF PORT NUMBER 1 
0088 * 
0089 0018 2z EQU $-CONSUM 
0090 0018 005A DATA >5A Z IN ASCII 
0091 * 
0092 001A RECMSG EQU $-CONSUM 
0093 001A 43 TEXT “CONSUMER RECEIVES ” 
0094 002cC 00 BYTE 0 
0095 * 
0096 002D TERMSG EQU $-CONSUM 
0097 002pD 43 TEXT “CONSUMER TERMINATES” 
0098 0040 OD BYTE >0D,>0A <CR><LF> 
0041 OA 
rf - 0099 0042 00 BYTE 0 <NUL> TO TERMINATE STRING 
| 0100 * | 
0101 0043 CRLF EQU $-CONSUM 
0102 0043 Op BYTE >0D,>0A,>00 <CR><LF><NUL> 
0044 OA 
0045 #00 
0103 0046 EVEN CODE MUST START ON WORD BNDRY 


_ 
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CONSUM SDSMAC 3.3.0 79.312 - 
CONSUM -- CONSUMER PROCESS FOR DEMONSTRATION PAGE 0005 
0105 KRKEKEKKKKKKKKRRRR KEKE KKK 
0106 * -~ PROCESS START CODE -- * 
0107 REEKRKKKKRRKEKRKKKRKRKKKKKKRKRKKKKE KKK 
0108 0046° PROLOG EQU $ | | 
0109 0046 CEAS8 MOV @FRMSIZ-CONSUM(CODE) ,*SP+ PUSH FRAME SIZE, BYTES 
0048 0008 
0110 004A CEA8 MOV @LEXLVL-CONSUM(CODE) ,*SP+ PUSH LEXICAL LEVEL 
004c OO0A 
0111 004EF CEA8 MOV @PRIORI-CONSUM(CODE) ,*SP+ PUSH PRIORITY 
0050 000c | 
0112 ve Pepe MOV @STKSIZ-CONSUM(CODE) ,*SP+ PUSH STACKSIZE, WORDS 
005 OOF 
0113 0056 CEA8 MOV @HPSIZE-CONSUM(CODE) ,*SP+ PUSH HEAPSIZE, WORDS 
: 0058 0010 
0114 005A 0000 DATA CALL$,S$PRCS START THIS PROCESS 
005c 0000 
0115 REKRRKRKRKRKRRKEKKKRKRKEKRRKRKRKRKRKRKRKEKRKRKKRRKKRKRKRKKKEKRKKRKRRKKKRRKREKRKKERKREEE 
0116 * ALLOCATE CHANNEL “CHNAME~*, PUT RESULT IN “CHNLID~ * 
0117 REEKKKKKRKKRKRKKRKRREKRKEKRKREKKRKRKRKKKRKEKRKEKKKRKRKEKRKRKRRKRKRRKKRRKKRKRKRKRKRKRARKRKRKEEE 
0118 OOSE CEA8 MOV @CHNAME(CODE) ,*SP+ PUSH NAME OF CHANNEL (1) 
0060 0012 
0119 0062 c089 MOV LF, TEMP “PUSH PTR TO CHANNEL ID 
0120 0064 0222 AI TEMP,CHNLID ¢ (LOCAL FRAME+OFFSET) 
0066 0000 ~ 
0121 0068 cE82 MOV TEMP, *SP+ : 
0122 006A 005A’ DATA CALLS,CSINIT ALLOCATE THE CHANNEL 
006c 0000 
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CONSUM 


CONSUM -- CONSUMER PROCESS FOR DEMONSTRATION 
HHKK KKK KK KEKE IKKE KEK EERE KEK EEK ERE EEE KEKE EEKEEREEE 


* UNTIL “CHAR” EQ “Z° RECEIVE CHARACTER MESSAGE : 
HH KKH KKK KEKE KEE KEKE REE EEK ERR ER EEE ERE EREEEEREREEEERERE 


0124 
0125 
0126 
0127 


0128 
0129 


0130 
0131 


0132 
0133 
0134 
0135 
0136 
0137 


0138 
0139 


0140 
0141 


0142 
0143 


0144 
0145 
0146 


0147 
0148 


0149 


0150 
0151 


0152 
0153 


0154 
0155 
0156 
0157 
0158 


0O06E 
0070 
0072 
0074 
0076 
0078 
007A 
007C 


O07E 
0080 
0082 
0084 
0086 


~0088 
008A 


008C 
008E 
0090 
0092 
0094 


0096 


0098 


009A 
009C 
009E 
OOA0 
O0A2 
O0A4 


OOA6 
OOA8 
OOAA 
OOAC 
OOAE 
00BO0 
00B2 
00B4 
OOB6 
OOB8 


OOBA 
OOBC 
OOBE 


SDSMAC 3.3.0 79.312 


CEA9 WAITLP MOV @CHNLID(LF) ,*SP+ PUSH CHANNEL ID 

0000 

c08s9 MOV. LF, TEMP PUSH PTR TO MSGBUF 

0222 AI TEMP ,MSGBUF : (LOCAL FRAME+OFFSET) 

0002 

CE82 MOV TEMP, *SP+ : ! 

006A° DATA CALLS ,CS$RECE WAIT FOR MESSAGE ! 

0000 
De CT ae a eT ee Re Oe ee ee Se ee Re EO ee 
* WRITE “CONSUMER RECEIVES c” 
KKKKKKKEKEKKEKEKEKEKEEKKK EEK KKRKRKKEK: 

c069 MOV @MSGBUF (LF) ,MP MOVE VALUE TO REGISTER MP 

0002 

ae MOV @PORTO1(CODE) ,*SP+ PUSH CRU BASE OF PORT 1 

CEA] MOV @BSLOT(MP) , *SP+ PUSH BAUD RATE FLAG 

0002 

co08ss MOV CODE, TEMP PUSH PTR TO MESSAGE 

0222 AI TEMP, RECMSG : (CODE BASE+OFFSET) 

OO1A 

CE82 | MOV TEMP, *SP+ 3 

007A° DATA CALLS, TISMSG WRITE THE STRING 

0000 | 
* 

CEA8 MOV @PORTO1(CODE) ,*SP+ PUSH CRU BASE OF PORT 1 

0016 

CEA] MOV @BSLOT(MP) , *SP+ PUSH BAUD RATE FLAG 

0002 

CEA] MOV @CSLOT (MP) , *SP+ PUSH THE CHARACTER 

0000 

00927 DATA CALLS, TISCOT WRITE THE CHARACTER 

0000 
* 

CEA8 MOV @PORTO1(CODE) ,*SP+ PUSH CRU BASE OF PORT 1 

0016 | 

CEA1 MOV @BSLOT(MP) , *SP+ PUSH BAUD RATE FLAG 

0002 

c088s MOV CODE, TEMP PUSH PTR TO MESSAGE 

0222 AI TEMP , CRLF ¢ (CODE BASE+OFFSET) 

0043 

CE82 MOV TEMP, *SP+ : 

00A2~* DATA CALLS, TISMSG WRITE THE STRING 

00947 | | 
KREKKKKEKAKEEKKEE KEE KEKE EERE KEE REE KEKE REREKEEKEEKRERKEEEEREKEKEEERER 
* ACKNOWLEDGE RECEIPT OF THE MESSAGE te 
REKKEEKKEKEKEEKEEEKEKEEERERREREEEKEEEKEKEEEEEEEKEEEEEERKEEERKEEEEEE 

CE81 MOV MP,*SP+ PUSH MESSAGE BUFFER PTR 

Bee. DATA CALLS ,CSACKN ACKNOWLEDGE THE MESSAGE 


\ 
! 
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Syren cea ty 8p 


0159 | ERRRRREREER ARE RRREERERRRREREERERERRERRRRREREERRERERRERE RE RRR 





0160 * END { UNTIL “CHAR’ EQ °2” } ae 
0161 LA eee EERE EE EEE ELE TOES EE LETT TT Terr rrrrrrTrrrTtrrrrrrrrrrrgt 
0162 00cO 8a21 Cc @CSLOT(MP) ,Z(CODE) IS CHARACTER °2°? 

00c2 0000 , 

00c4 0018 
0163 00C6 16pD3 JNE WAITLP NO: LOOP 
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~ CONSUM -- CONSUMER PROCESS FOR DEMONSTRATION PAGE 0007 
0165 KEKEKEK KEK KKK KEKE KKK KEKE 
0166 * FREE “CHNLID* * 
0167 HH KKK KEKE KKK KEK IKE EEK EKER EKER EKER ERE EE EEE EKREEEKEREEES 
0168 00C8 CEAO MOV @CHNLID, *SP+ PUSH CHANNEL ID 3 
0OcA 0000 
0169 00cc 00BC* DATA CALLS,CSTERM FREE THE CHANNEL 
OOCE 0000 | | 
0170 KKKKKKKKKKKKK KEKE EKER KEKE 
0171 * WRITE “CONSUMER TERMINATES” x 
0172 HHKKKKKKEKKEKK KEKE KEKE KEK EKER EEE KERR ERE ERE KREREKREREREEEREER | 
0173 OOpO CEA8 MOV @PORTO1 (CODE) ,*SP+ PUSH CRU BASE OF PORT 1 | 
0OOp2 0016 | 
0174 00D4 CEAI1 MOV @BSLOT(MP) , *SP+ PUSH BAUD RATE FLAG | 
OOD6 0002 7 : 
0175 OOD8 cO8s MOV CODE, TEMP PUSH PTR TO MESSAGE 
0176 OODA 0222 AI TEMP , TERMSG ¢ (CODE BASE+OFFSET) 
0Opc 002p : - 
0177 OODE CE82 MOV TEMP, *SP+ | 
0178 OOEO 00CcC” DATA CALLS, TISMSG WRITE THE STRING ! 
OOE2 O00B8’ 
0179 KEEKKEKEKEEEEEEEEEREEKERKKEEKREKEEEKERKEKREEKEKKEKEKEEEKKKEKKEKRKKKEE 
0180 * _ «<< PROCESS TERMINATION CODE -- * 
0181 KKEKKEKEEEKKEEKEEKEKEEREEEKEEKEEKEEEEKKEEEEKEEEEKEEKKKKKKKEKEKKRE ! 
. 0182 00OE4* EPILOG EQU §$ 
f 0183 OOB4 CEA8 | MOV @LEXLVL-CONSUM(CODE) ,*SP+ PUSH LEXICAL LEVEL 
| OOF6 OOO0A 
0184 OOE8 OORO’ DATA CALLS$,ESPRCS TERMINATE THIS PRCS 
OOEA 0000 
0185 O0EC 0460 B @EXITSP EXIT 
OOEE 0000 7 
0186 END 
NO ERRORS, NO WARNINGS 
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WAITIO SDSMAC 3.3.0 79.312 
TISLIB -- WAIT LOOP DRIVEN I/O -- 6/25/80 
0002._— IDT *WAITIO® ' 
0003 DEF TISSET 
0004 DEF TISCIN 
0005 DEF TISCOT 
0006 DEF TISMSG 
0007 * | 
0008 reeeeRERRERERE REE ERE RE ERE REE RE RE SESE EEE RE LE SEES EERE SRE EE EEE SS 
0009 * : 
0010 * TISSET: SET THE BAUD RATE OF A TERMINAL 
0011 * 
0012 * 
0013 * PURPOSE: THIS ROUTINE AUTO-BAUDS A TERMINAL ATTACHED 
0014 * TO A 9902 INTERFACE. WHEN CALLED, IT INPUTS 
0015 * A CHARACTER (EITHER AN “A* OR A <CR>) AND 
0016 * TESTS THE LENGTH OF THE START BIT TO FIND 
0017 * THE BAUD RATE. THE 9901 TIMER IS USED TO 
0018 * TIME THE START BIT. | 
0019 * 
0020 * CALLING_SEQUENCE: 
0021. * PUSH CRU ADDRESS OF PORT 
0022 * PUSH POINTER TO BAUD RATE FLAG 
0023 * CALL TISSET 
0024 * 
0025 * MOV @<CRU ADDRESS>, *SP+ 
0026 * MOV @<ADDRESS OF BAUD RATE FLAG>, *SP+ 
0027 * DATA CALL$,TISSET 
Q028 3 | 
0029 * INPUTS: THE CRU ADDRESS OF THE PORT IS USUALLY >80 
0030 * FOR PORT ONE AND >180 FOR PORT TWO. 
0031 * 
0032 * OUTPUTS: TISSET INITIALIZES THE 9902 PORT AND SETS 
0033 * THE BAUD RATE. THE BAUD RATE FLAG (THE 
0034 * SECOND PARAMETER) IS SET TO THE PROPER 
0035 * VALUE WITH WHICH TO SET THE XDR AND RDR 
a * VALUES OF THE 9902. VALUES USED ARE: 
37 * 
0038 * BAUD: INIT CHAR (12 BITS) 
0039 * 19200 >O01A 
0040 * 9600 >034 
0041 * 4800 >068 
0042 * 2400 >0D0 
0043 * 1200 >A10 
0044 * 600 >340 
0045 * 300 >4pD0 
0046 * 110 >638 
0047 * 
0048 * EXCEPTIONS: NONE. 
0049 * 
0050 * CALLS: NONE. 
0051 * : 
0052 * REFERENCES: TMS 9901 PROGRAMMABLE SYSTEMS INTERFACE 
0053 * | COPYRIGHT 1978 By TI INC., NUMBER MP003 


eeeee ee ee” © ee He eH He FH 


+e Fe ee OOO 














_ 


. 0054 


0055 
0056 
0057 
0058 
0059 


* 


* 
* TMS 9902 ASYNCHRONOUS COMMUNICATIONS ~ * 
* CONTROLLER DATA MANUAL, a 
- COPYRIGHT 1978 By TI INC., NUMBER MP004 * 
* * 


| 
KKKKKKHKKEKKKEKEKKEEERKEKKEKEEEEKKEKKEKEKEEKREEEKERKEEKEKKEKEES 
| 
| 
| 
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IS$LIB -- WAIT LOOP DRIVEN I/O -—- 6/25/80 
* ROUTINE LIST: 


0061 
0062 
0063 
0064 
0065 
0066 
0067 
0068 
0069 
0070 
0071 
0072 
0073 
0074 
0075 
0076 
0077 
0078 
0079 
0080 
0081 
0082 
0083 
0084 
0085 
0086 
0087 


000D 
000F 
0010 
0012 
0015 


0016. 


001F 
0100 


0001 
0002 
0003 
0004 


0007 
0008 
0009 
000A 


000c 


* 


+ + + 


* 


LDIR 
RIN 


RTSON 
RIENB 


RBRL 
XBRE 


RESET 
CB9901 
* 


BAUDP 
COUNT 
TBLPTR 
TIMVAL 
* 


PR 
CODE 
LF 


SP 
* 


CRUBAS 
7 


TISSET 


EQUATES 


EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 


EQU 


-EQU 


EQU 
EQU 


EQU 
EQU 
EQU 
EQU 


EQU 


13 
15 


16 


18 
21 
22 


>100 


fm WN 


© © ~] 


9902 
9902 
9902 
9902 
9902 
9902 
9902 
9901 
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- LOAD INTERVAL REGISTER 
- RECEIVE INPUT BIT 

- REQUEST TO SEND ON 

~ RECEIVER INTERRUPT ENABLE 

- RECEIVER BUFFER REGISTER LOADED 
- TRANSMIT BUFFER REGISTER EMPTY 
- RESET BIT 

CRU BASE 


co 











0089 
0090 
0091 
0092 
0093 
0094 
0095 


0096 
0097 


0098 
0099 


J100 
0101 
0102 
0103 
0104 


0105 
0106 
0107 
© 1108 


“9109 


0110 
0111 
0112 
0113 
0114 
0115 


1116 
vill 
0118 
0119 
0120 
0121 
0122 
0123 
0124 
0125 
0126 
0127 
0128 


0129 
0130 
0131 


\ . oe 


“ \ITTIO 


0000 
0000 


0002 
0004 
0006 
0008 
000A 
000C 
000E 
0010 
0012 


0014 
0016 
0018 
001A 


00lc 
0O01E 
0020 


0022 
0024 
0026 


0028 
002A 
002C 


002E 
0030 


0032 
0034 
0036 
0038 
003A 
003C 
003E 
0040 


| SDSMAC 3.3.0 79.312 
¥ISLIB -- WAIT LOOP DRIVEN 1/0 -- 6/25/80 
PSE 
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0000° TISSET EQU "§ 


0000 


C2AD 
0014 
022A 
FFFC 
CB4A 
0014 
C31A 
CO6A 
0002 


1D1F 
3220 


005c” 


1EOD 


04C2 
1FOF 
13FE 


020C 
0100 
0704 


1E00 
33C4 
1EOO 


1000 
1000 


C31A 
LFOF 
16FE 
020C 
0102 
1DFF 
3782 
LEFF 


DATA 0 OPTIMIZED LINKAGE 


Keka KKH HK KK IKKE KERRIER EEE KER EERE 


* GET ARGUMENTS sie 
KKKKHKHKKEEEKKKEKEEKKEKKKEKEEKEEKEKEEEKKEEKEEEEEKEKEEEEEEKEEEKEEEEE | 


MOV @SP*2(R13),SP GET CALLER“S SP 

AI SP,-4 RESET SP 

MOV SP,@SP*2 (R13) RESTORE CALLER“S SP 
MOV *SP,CRUBAS SET CRU BASE OF PORT 
MOV @2 (SP) ,BAUDP SET BAUD POINTER 


HAEKKKKKEKKEEKEKKEKEEEEKEEKEKREKEEEKKEKEEEEKEEKEKEREKEKEREREELR 


is INITIALIZE THE 9902 * 
HKKEKKKKKEKEKIEKEKEKEEKEKREKEEKEKEREEREEERKEEREEEKEEEKERREKKKEK 


SBO RESET RESET THE 9902 
LDCR @CONTRL, 8 LOAD CONTROL REGISTER 
SBZ LDIR DISABLE INTERVAL TIMER 


KKEKEEKKEREKEEEEAKEAKEEREEEREEKKEEKEKEKEKEKEKKEEKEKERAEKKKKEKEE : 


id WAIT FOR CHARACTER © . 
KAKKKKKKEKEKKKEKKKREEKKEEREEKEKEKEKEREEEEREREEEEEREREREERERKE 


CLR ~~ COUNT CLEAR TIMER COUNT 
TESTSP TB RIN SPACE? 
JEQ #$TESTSP NO: TEST AGAIN 
KREKEKEEKEEEEEKEKEEEEEKKEKEKEKTEEEEEEERERKEKEEEEEEEEKEKEKERERKEE 
* INITIALIZE 9901 AND TIME SPACE BIT * 


HRAREKKEEREEEEEKEEEEEEEKEEKEEEEREREKEEKKEREKEKEKEEEEEREKREEKEKEE 


LI CRUBAS ,CB9901 SET CRUBASE AT TMS9901 
SETO  TIMVAL INITIAL TIMER VALUE >3FFF 
x : CONTROL BIT IS GETS 1 
SBZ 0 SET 9901 TO INT. MODE 
LDCR TIMVAL,15 LOAD AND START 9901 TIMER 
SBZ 0 CONTROL BIT = 1, SET TO 0 
* > TO TURN INT. ON 
NOP... DELAY WHILE 9902 SETS BIT 
NOP : (FOR 1481) MUST WAIT 
* , : BEFORE CHANGING BASES. 
MOV *SP,CRUBAS SET CRU BASE TO 9902 PORT 
TIMELP TB RIN STILL SPACE? 
JINE TIMELP FALL OUT ON MARK 
LI CRUBAS ,CB9901+2 BASE OF 990l+<1 BIT> 
SBO -1 SET 9901 TO CLOCK MODE 
STCR COUNT,14 STORE 9901 COUNT VALUE 
SBZ =] SET 9901 TO INT. MODE 
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WAITIO 


0133 
0134 
0135 
0136 
0137 
0138 
0139 
0140 
0141 
0142 
0143 


0144 


0145 
0146 


0147 


0148 
0149 
0150 
0151 
0152 
0153 
0154 
0155 
0156 
0157 
0158 
0159 
0160 
0161 
0162 
0163 
0164 
0165 
0166 
0167 
0168 
0169 


0170 
0171 
0172 
0173 
0174 
0175 
0176 


0042 
0044 
0046 
0048 


004A 
004Cc 
004E 
0050 
0052 
0054 
0056 


0058 


005A 


005c 


OO5E 
0060 
0062 
0064 
0066 
0068 
006A 
006C 
006E 
0070 
0072 
0074 
0076 
0078 
OO7A 
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C31A 
1F15 
16FE 
1E12 


0203 


005E” 


8CC2 
1402 
05¢c3 
10FC 
3313 


C453 


0380 


62 


3FFD 
OO1A 
3FF8 
0034 
3FFO 
0068 
3FE1 
00p0 
3FCl 
01A0 
3F82 
0340 
3EC9 
04D0 
0000 


09:59:39 THURSDAY, MAY 07, 1981. 


TRE RRESERELERERE LEE EEE ELAR E EEE EERE EE EE EEE EEE LES EEE EE TEETER EES SE 


* RESET FOR 9902 PORT AND IGNORE THE AUTO-BAUD CHARACTER * 
KHKKKKKKEKEKEKREEREKEKEAEEREKEREREREEIKEREKEEEKEEKEKEAEREKRRERKRRRAE 


: MOV  *SP,CRUBAS SET CRU BASE TO 9902 PORT 
LOADLP TB RBRL CHARACTER FINISHED? 

JNE § LOADLP NO: CHECK AGAIN 

SBZ RIENB RESET RBRL 
ree eeeERERRERAELEEE RE RRR EEE LER ESE LER ESE EEE ELE REE ILE LEE EEL ERE SE SS 
LOOK UP COUNT IN BAUD TABLE * 


REAREKEKERREEEREREEEKEKEREEEKERREREEKEKEEREKKEERERERRKRRREREKKEEE 


LI TBLPTR, BAUDTB GET ADDRESS OF BAUD TABLE 
BAUDLP C COUNT, *TBLPTR+ MATCH IF HIGH OR EQUAL 
JHE MATCH YES, SET BAUD RATE 
INCT  fTBLPTR NO, UPDATE TABLE PTR | 
JMP BAUDLP | 
*TBLPTR, 12 INITIALIZE RDR,XDR, 


MATCH LDCR 
* RESET LRDR, LXDR 

MOV *TBLPTR, *BAUDP SET RETURNED BAUD RATE 
RHKKEKKKEKREEKEKEKEKEEEEKRKEEKEKEEREEKEERREEREREKKEKRAEAAKRKEKRKEKRKREEK 


TReREEEEREREE SERRE EERE LE LES EEL ELE EEL EE EERE EE ERE EEL ERE RARER E LES SE 
RTWP : 
Le eeeeeeESER ERE EEE SRE ERE LER EL ERE LAE EE ES EEE ESET TEETER EEL EEE ES 


* --- DATA SECTION --- eS: 
t-eEEeEREREREEER ESLER EREL ERE EE LE LEA ERE ERE RE RTE REE EEE EEE LER EL EE SS Bee 


* 


CONTRL BYTE >62 9902 CONTROL REGISTER VALUE 
* 


SPECIFIES : TWO STOP BITS 


* EVEN PARITY 
* 7 BITS/CHAR 
* 
* 9901 TIMER VALUE (14 BITS) 9902 — RATE FLAG | 
¥ : 
: ( 

* he stl tae ia es Ss te a es sce + 
. | 
* V V 
BAUDTB DATA >3FFD,>01A BAUD = 19200 

DATA >3FF8 ,>034 BAUD = 9600 

DATA >3FFO,>068 BAUD = 4800 

DATA >3FE1,>0D0 BAUD = 2400 

DATA >3FCl1,>1A0 BAUD = 1200 

DATA »>3F82,>340 BAUD = 600 

DATA >3EC9,>4pD0 BAUD = 300 

DATA BAUD = 110 


>0000,>638 
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0178 
0179 
0180 
0181 
0182 
0183 
0184 
0185 
0186 
0187 
0188 
0189 
0190 
0191 
0192 


0193 


0194 
0195 
0196 
0197 
0198 
0199 
0200 
0201 
0202 


0203. 


0204 
0205 
0206 
0207 
0208 


0209 
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PAGE 0006 ~ 


kReRKKKRKKKKKKRKRK KKK KKEKKKKKEKRRKKKKKREKKKKKRKRKKKEKEE 


+e eee + ee He He He HH EH HH eH He HH HH Oe OF OO Om OF * 


TISCIN: 


PURPOSE: 


INPUT A CHARACTER 


THIS ROUTINE INPUTS A CHARACTER FROM A PORT 


OF A 9902. THE.CHARACTER IS NOT ECHOED. 


CALLING SEQUENCE: 


INPUTS : 


OUTPUTS : 


PUSH CRU ADDRESS OF PORT 
PUSH ADDRESS OF WORD TO RECEIVE CHARACTER 
CALL TISCIN 


MOV @<CRU ADDRESS>, *SP+ 
MOV @<POINTER TO WORD>, *SP+ 
DATA CALLS, TISCIN 


THE CRU ADDRESS OF THE PORT IS USUALLY >80 
FOR PORT NUMBER ONE, AND >180 FOR PORT TWO. 


THE CHARACTER IS STORED IN THE LOW 7 BITS 
OF THE WORD POINTED TO BY ARGUMENT TWO. 


EXCEPTIONS: NONE. 


CALLS : 


NONE. 


REFERENCES : ‘TMS 9902 ASYNCHRONOUS COMMUNICATIONS 


CONTROLLER DATA MANUAL, 
COPYRIGHT 1978 BY TI INC, NUMBER MP004 


te 


oe OF ee ob OF oF be Oe 


HRAEARAEEREKREKKRERERRERERERRKERKKREKEKEREKAEEKERRERKRRKEKRERKRRKRERARKKREK 
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0211 
0212 
0213 
0214 
0215 
0216 
0217 
0218 
0219 
0220 
0221 
0222 
0223 
0224 


0225 
0226 


0227 
0228 


0229 
0230 


{9231 
“9232 


0233 
0234 
0235 
0236 
0237 
0238 
0239 
0240 


~ 0241 


| WAITIO 


O07E 
0O7E 


0080 
0082 
0084 
0086 
0088 
008A 
008C 
008E 
0090 


0092 
0094 
0096 
0098 
009A 
009C 


009E 
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0001 


007E° 


0000 


C2AD 
0014 
022A 
FFFC 
CB4A 
0014 
C31A 
CO6A 
0002 


1F15 
16FE 
04pl 
35D1 
06pDl 
1E12 


0380 
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* EQUATES 


CHARP EQU 1 
* PROGRAM SEGMENT 
* 


PSEG 


TISCIN EQU $_ 
DATA 0 OPTIMIZED LINKAGE 
KEAKKKKEKKKEAKKEKEKE KEKE EKER ERAKEEKEEREEKERERERREREEERERERESK 


sg GET ARGUMENTS . 
KHRKKKKKKKKEKKEAKEEEKEEEKEEKEREKEREREEEEEEEEEERKEEEEEEEEEEREEEEEK 


MOV @SP*2(R13) ,SP GET CALLER’S SP 

AI SP,-4 RESET SP 

MOV SP, @SP*2 (R13) RESTORE CALLER“S SP 
MOV *SP,R12 SET CRU BASE OF PORT 
MOV @2(SP) ,CHARP SET BAUD POINTER 


RAKKKEEKEREKEEEKEKEEREEEEEEKKKEKEEKEREKEKEKKEKEKEKEKKKKKKKKKKKKKKK 


x WAIT FOR CHARACTER AND STORE IT id 
KKKKEKKEKRKEKEKEKEEKEKEREREREERKEEREKEEEEEEREKEEKEREKKEKKKKKKKEKKK 


WAITLP TB RBRL BUFFER FULL? 
JNE WAITLP NO: WAIT 
CLR *CHARP YES: STORE IN LOW BYTE 
STCR *CHARP, 7 : OF WORD POINTED TO 
SWPB * CHARP : BY CHARP 
SBZ RIENB RESET RBRL 


KEKKKEKEEKEKEKEKEKEKEEKKEEKEREKEEEKEEKEEEEEEKEREKKEEKEKEKKEKEKE 


* ---- END OF CODE ---- * 


KHEKEKEEKEEEEEKEEEEKKKEKEKEEREEKKEKEEEEEEKEEEKEKEEKKEEKEEEEEKEL 


RTWP 
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0243 PRR REESESEAELE LE LEE SESE SESE SEE SESE SESE TELE TS EEE ET ESET LEE RL ESS 
0244 * | | | * 
0245 * TISCOT: OUTPUT A CHARACTER * 
0246 * | * 
0247 * | * 
0248 * PURPOSE: THIS ROUTINE OUTPUTS A CHARACTER TO A PORT * 
0249 * OF A 9902. IF THE TERMINAL IS A 1200 BAUD * 
0250 * PORT THE CHARACTER IS PADDED WITH 3 NULLS. * 
0251 * IF THE CHARACTER WAS A <CR>, IT IS PADDED * 
0252 * WITH 3 TO 23 NULLS, DEPENDING ON THE BAUD * 
0253 * RATE, TO GIVE A 200MS DELAY. * 
0254 * | * 
0255 * CALLING_SEQUENCE: . 
0256 * PUSH CRU ADDRESS OF PORT * 
0257 * PUSH BAUD RATE FLAG st 
0258 * PUSH WORD, RIGHTMOST BYTE OF WHICH IS CHAR’ - 
0259 * CALL TISCOT * 
0260 * * 
0261 * MOV @<CRU ADDRESS OF PORT>, *SP+ tk 
0262 * MOV @<BAUD RATE FLAG>, *SP+ * 
0263 * MOV @<WORD>, *SP+ * 
0264 * DATA CALL$,TISCOT ud 
0265 * | * 
0266 * INPUTS: PORT: CRU ADDRESS OF USER PORT, USUALLY me 
0267 * >80 FOR PORT 1, AND >180 FOR PORT 2. | 
0268 * BAUD: BAUD RATE FLAG SET BY TISSET aod 
os * WORD: LOW 7 BITS OF WORD ARE OUTPUT CHAR. : 
¥e : 
0271 * OUTPUTS: WRITES CHAR TO PORT, PADDED WITH 3 NULLS IF * 
0272 * 1200 BAUD. PADS <CR> WITH NULLS TO GIVE A * 
0273 * 200MS DELAY. * 
0274 * * 
0275 * EXCEPTIONS: NONE. * 
0276 * 
0277 * CALLS: TISCOT * 
0278 * * 
0279 * REFERENCES: TMS 9902 ASYNCHRONOUS COMMUNICATIONS * 
0280 * CONTROLLER DATA MANUAL, id 
et * COPYRIGHT 1978 BY TI INC, NUMBER MP004 : 
282 * 
0283 re PRES REEESE SE RESCAEEAESES ESSE ERE ESLER ERSEESERERESREE REE AZE SESE! 
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0285 * | 
0286 * EQUATES 
0287 * 
0288 0001 BAUDFL EQU 1 \ 
0289 0002 TABLEP EQU 2 
0290 0003 CHR EQU 3 
0291 0004 PADNLS EQU 4 
0292 0005 CRNULS EQU 5 
0293 0006 NUMNUL EQU 6 
0294 * 
0295 * PROGRAM SEGMENT 
0296 * 
0297 OOAO PSEG 
0298 OOA0O” TISCOT EQU $ 
0299 OO0AO 0000 DATA 0 OPTIMIZED LINKAGE 
0300 | KKEKKKKKEKEEKKKKEKEKEKEKEEEKEEEEEKEEKEKEEEKEEEEKKEREEKEEEKEER 
0301 * ---- GET ARGUMENTS ---- | | 
0302 HKEKKKEKKEKEEKEKEEEEEKEREEKEEEEKEKEEKEEREREKEKEKEKEEEREKERREER 
0303 OOA2 C2AD MOV @SP*2 (R13) ,SP GET CALLER’S SRP 
0O0A4 0014 | 
0304 OOA6 022A AI SP,-6 RESET SP 
OOA8 FFFA 
0305 OOAA CB4A MOV SP, @SP*2(R13) RESTORE CALLER’S SP 
OOAc 0014 
0306 OOAE C31A MOV *SP,R12 SET CRU BASE OF PORT 
0307 OOBO CO6A MOV @2(SP) ,BAUDFL BAUDFL := SECOND ARG 
OOB2 0002 
0308 00B4 COEA MOV @4(SP) ,CHR CHR := THIRD ARG 
OOB6 0004 | 
0309 OOB8 06cC3 SWPB CHR PUT CHR INTO TOP BYTE 
0310 KKEKKKAKKKEREKEEKEEEEEKEEKEKEREKEKKKEREEEEKEKKEKEEEKEKREEERERER 
0311 * --- SEND CHARACTER --- 
0312 KKK KEKE EKEEKEKKREEKEKEEEREEKEEEKEKEEEKEKREKEEEEEE 
0313 OOBA 1p10 SBO RTSON SET REQUEST TO SEND 
0314 OOBC 1F16 WTLPS1 TB XBRE TRANSMIT BUFFER EMPTY? 
0315 OOBE 16FE JNE WTLPS$1 NO: CHECK AGAIN 
0316 00C0 3203 LDCR  CHR,8 YES: SEND CHARACTER 
0317 KEKKKKEKEKKRKEKEEKEEKEKKEEKEKEKEEKEKEEEEEEEEEEREKEEKEEEEKERKEEE 
0318 * --— LOOK UP NULLS IN BAUDFL RATE TABLE --- 
0319 KREEKKEKEKKKREEKEKREKEEKEEKEKEKEEEEEEEEEEEEKEEEEEKEEEEEKEKREKREEER 
0320 00c2 0202 LI TABLEP, TABLE LOAD TABLE POINTER 
00c4 O0OFE” : 
0321 00c6 8Cc81 TBLLP C BAUDFL, *TABLEP+ MATCH? 
0322 00c8 1203 JLE FOUND YES: GET NUMBER OF NULLS 
0323 OOCA 0222 AI TABLEP, 4 NO: UPDATE TABLE POINTE 
00cc 0004 | 
0324 OOCE 10FB JMP TBLLP LOOP 
0325 00p0 c132 FOUND MOV *TABLEP+, PADNLS NUMBER OF NULLS PADDED 
0326 00D2 C152 MOV *TABLEP , CRNULS NUMBER OF NULLS AFTER CR 
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ISLIB -- WAIT LOOP DRIVEN I/O -— 6/25/80 PAGE 0010 
0328 7 A Er ae ee er ee ee rae 
0329 * -~-- SET NUMBER OF NULLS TO PAD --- 7 * 
0330 y RkekeKRKKKKRKKK KKK KEREKAEREER 
0331 O00p4 9803 CB CHR, @CR CARRIAGE RETURN? 

0OOD6 OOFS” 
0332 00D8 1302 JEQ PADCR YES: PAD CR 
0333 OODA c184 MOV PADNLS , NUOMNUL NO: PAD REGULAR CHR 
0334 00pc 1001 JMP PAD JMP TO PAD CODE 
0335 OODE C185 PADCR MOV CRNULS , NUMNUL PAD REGULAR CHR 
0336 REKKRKKKKKRKREKKKEKKKKKKKRRKKKKKRKRKRRKKRKRRRKKRRKKRRKKRRKRKKRKRKRKRKRKEEEK 
0337 * <<< PAD WITH NUMNUL NULLS --- * 
0338 EARARKERAREREREERRERERERERERERREREERERERRERERERREERERERERERERER 
0339 OOEFO C186 PAD MOV NUMNUL, NUMNUL IS NUMNUL ZERO? 
0340 O0O0EF2 1306 JEQ SENDOF YES: EXIT 
0341 OOE4 1F16 WTLPS2 TB XBRE TRANSMIT BUFFER EMPTY? 
0342 OOER6 16FE JNE WTLPS$ 2 NO: CHECK AGAIN 
0343 OOES8 3220 LDCR @NULLCH,8 SEND CHARACTER 

OOEA 00F4” 
0344 O0EC 0606 DEC NUMNUL DECREMENT NUMBER NULLS 
0345 OOEE 10F8 JMP PAD PAD AGAIN 
0346 rE ReEeRERESESESR EE ESSE SEE SELES LEE EEE PETES EP EET EP ESE TEE TE EEL ERT SE SY 
1347 * --—- DONE, TURN OFF REQUEST TO SEND --- * 
0348 reEREeREECEEE REESE SELES ESE EES EEE RE EEE ESTEE ESET ETE TELE EEE EEE EEE SE SY 
0349 OOFO 1£10 SENDOF SBZ RTSON BRING RTS HIGH AFTER ~ oe 
2350 * | : CHARACTER HAS FINISHED . 
7351 KRKEKKKKAKEKEKEEKEKKEREREREKKEKRKEKERKEEKEKEKRRKRRRKRRKRKEKRKEKRKRKRKRKRKRKRRRRKREE 
1352 * -~-- END OF CODE ---- * 
1353 KRREKKKKKKKKEREKEKKEARKRKKEKRRKRKKRKEREKRKEKKERKEKRKRKKKRKKRKRKRRKKEKRRKEKRRREKRS 
1354 OOF2 0380 RTWP 
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A np et. en, Se 





0356 
0357 * --- DATA --- ee 
0358 HEKEREKKKEKKRKEEKEREEEEEREKEEERREEEEREEEEEREREREEREREREEEREE 
0359 * = 
0360 O0F4 00 NULLCH BYTE >00 
0361 OOFS OD CR BYTE >0D 
0362 * 
0363 OOF6°* TABLE EQU $ ie :, 
0364 * ee, ee 
0365 * BAUDFL RATE FLAG, an eee CHR, NULLS AFTER CR. | 
0366 * | ee 
0367 * +———————— + | : 
0368 * fone ene nme nner eee reese eemaa= + 
0369 * | 
0370 * Vevv 
0371 OOF6 OO01A DATA >01A,0,0 BAUDFL = 19200. 
OOF8 0000 | 
OOFA 0000 
0372 O0FC 0034 DATA >034,0,0 BAUDFL = 9600 
OOFE 0000 | 
0100 0000 7 
0373 0102 0068 DATA >068,0,0 BAUDFL = 4800 - 
0104 0000 
; 0106 0000 | 
-. 0374 0108 OODOD DATA >0Op0,0,0 BAUDFL = 2400 
© ge 010A 0000 | | 
010c 0000 | 
0375 010F 01A0 DATA »>1A0,3,23 BAUDFL = 1200 
0110 0003 | 
0112 0017 
0376 0114 0340 DATA »>340,0,11 BAUDFL = 600 
0116 0000 
0118 0008 
0377 011A 04pD0 DATA >4p0,0,7 BAUDFL = 300 
011c 0000 
011E 0007 
0°78 0120 0638 DATA >638,0,3 BAUDFL = 110 
0122 0000 
0124 0003 
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PAGE 001. ” 


ree SERESEARRESEEELES ELE RALELEELELE RE RE REREL ESLER ELE REEL EEL EELS SS 


CALLS : 


REF 
REF 
* 


* EQUATES 
* 


PORTOF EQU 
BAUDOF EQU 
MSGP EQU 
t 


MSGPTR EQU 
WORD EQU 


PURPOSE: 


INPUTS : 


OUTPUTS: 


REFERENCES 


TISMSG: OUTPUT A STRING, DELIMITED BY A NULL 


OUTPUT A STRING TO A 9902 PORT.. THE STRING 
IS COMPOSED OF CONSECUTIVE BYTES POINTED 
TO BY THE THIRD ARGUMENT, AND DELIMITED BY 
A ZERO BYTE. 


CALLING SEQUENCE: 


PUSH CRU ADDRESS OF PORT 
PUSH BAUD RATE FLAG FROM TISSET 
PUSH POINTER TO MESSAGE STRING 


MOV @<CRU ADDRESS>, *SP+ 
MOV @<BAUD RATE FLAG>, *SP+ 
MOV @<PTR TO MSG>, *SP+ 
DATA CALLS , TISMSG 


PORT: CRU BASE OF OUTPUT PORT 
BAUD: BAUD RATE FLAG FROM TISSET 
MSGP: POINTER TO MESSAGE STRING 


OUTPUT IS SENT TO PORT. 


EXCEPTIONS: NONE. 


TISCOT 


ree eeRERERRARERERERSEREREAERRERESLE LESSER ERE EERE SERRE REL E SALE LE SL ES 


CALLS 
EXITSP 


>0000 
>0002 
>0004 


ADDRESS 2 
INTEGER 2 
POINTER 2 


E-32 
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WAITIO SDSMAC 3.3.0 79.312 ast 

TISLIB -- WAIT LOOP DRIVEN I/O -- 6/25/80 PAGE 00 
0426 0126 PSEG | pie 
0427 0126° TISMSG EQU §$ " ea 
0428 0126 0008 DATA MSGENT-TISMSG OFFSET TO EXECUTABLE CO 
0429 0128 0024 DATA MSGEXI-TISMSG OFFSET TO TERMINATION C 
0430 012A 0000 DATA 0 LOCAL VARIABLE SIZE 
0431 012c 0006 DATA 6+0 LOCAL FRAME SIZE 
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0433 012E° MSGENT EQU- = $ - MSGENT POINT OF PROCESS 
0434 HKAKEKKKEREREREREREREREREREREEEEREEEEREREREREEEEERERERERERES 
0435 ‘ ---- MAIN BODY OF CODE ---- | 
0436 EHAEKEKKEKEREKEEEKERERERERRER REE ERE KREREREREERERERERERERERE | 
0437 012E C069 MOV @MSGP(LF) ,MSGPTR GET POINTER TO MESSAGE 

0130 0004 | 
0438 0132 04c2 CHARLP CLR WORD ZERO BOTH BYTES 
0439 0134 pOBl MOVB *MSGPTR+,WORD CHR IN HIGH BYTE OF WOR 
0440 0136 1309 JEQ  MSGEXI YES: QUIT 
0441 0138 CEA9 MOV @PORTOF(LF) ,*SP+ PUSH PORTOF 

013A 0000 
0442 013C CEA9 MOV @BAUDOF(LF) , *SP+ PUSH BAUDOF RATE FLAG 

- 013E 0002 

0443 0140 06c2 SWPB WORD CHR IN LOW BYTE OF WORD 
0444 0142 CE82 MOV WORD, *SP+ PUSH WORD ON STACK 
0445 0144 0000 DATA CALL$,TISCOT SEND CHR 

0146 OOA0~ 
0446 0148 10F4 JMP § _CHARLP | 
0447 KEEKKEKEKEKEEKEKKKEKEEKREKEEEEEEEKEKEKEKKKEKEKEEKEEEETEKEEKEEKEEKKRE 
0448 * ---- END OF CODE ---- 
0449 KKREEKEKEKEKEEEEKEREKEEKEKEEEKKEEKKEEEEKKEEKEKEKEKEKEKEEEKEAEKKERTR 
0450 014A° MSGEXI EQU- $ EXIT CODE 9 
-0451 014A 0460 B @EXITSP 

014c 0000 | 
0452 END 

NO ERRORS, NO WARNINGS 


E-33 


Se mtr Nat ee ee erm 3 eee en eee - + 


SDSMAC 3.3.0 79.312 16:57:27 WEDNESDAY, MAY 06, 1981. 


0002: 








5130 


IWPSZ 
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CONFIG 
| PAGE 
0001 IDT “CONFIG” SPECIFY CONFIGURATION | 
0002 * REVISION: 08/01/80 1.00 ORIGINAL FOR RX 2.0 
0003 * ROUTINE LIST: CONFIG, IWPSO .. IWPS$15, BADSWP, 
0004 * SRAMTB, SRESTA, SLREX, SSYSCR, 
0005 * SDEFAU, S$FILL, $STKSZ, SBOOTP, 
0006 * SIODIR, DBSWP 
0007 * COPY MODULES: 
0008 * NONE. 
0009 -* MACRO DEFINITIONS: 
0010 * NONE. 
0011 * EXTERNAL ROUTINES: 
0012. eS NONE. 
0013 * EXTERNAL DATA: 
0014 0000 PSEG 
0015 * MODULE CONSTANTS : 
0016 0018 IWwPSZ EQU 24 SIZE OF AN INTERRUPT 
0017 * WORKSPACE (R4-RL5) 
0018 5000 LOWRAM EQU- >5000. LOW BOUNDARY OF RAM 
0019 * MODULE VARIABLES: 
0020 * 
0021 5000 DORG LOWRAM 
0022 * | 
0023 DEF IWPSO,IWPS1, IWPS$2,IWPS3 
0024 DEF IWPS4,IWPS$5,IWPS6,IWPS$/7 : 
0025 DEF IWP$8,IWPS$9,IWPS10,IWPS11 
0026 DEF IWPS12,IWPS$13,IWP$14,IWPS15 
0027 DEF BADSWP,DBSWP 
0028 5000 IWPSO BSS 32 
0029 5020 IWPS1 BSS 32 
0030 5020 DBSWP EQU' IWPS1 
0031 5038 IwPS2 EQU $-32+IWPSZ 
0032 5040 BSS IWPSZ | 
0033 5050 IwPS3 EQU $—-32+IWPSZ 
0034 5058 BSS IWPSZ 
0035. 5068 IwPs4 EQU $—-32+IWPSZ 
0036 5070 BSS IWPSZ 
0037 5080 IwPS5 EQU $-32+IWPSZ 
0038 5088 BSS IWPSZ 
0039 5098 IWPS6 EQU $-32+IWPSZ 
0040 S50OA0 BSS IWPSZ 
0041 50B0 IWPS7 EQU $-32+IWPSZ 
0042 50B8 BSS IWPSZ 
0043 50c8 IwWP$8 EQU $-32+IWPSZ 
0044 50D0. BSS IWPSZ 
0045 50EO IwPS9 EQU $—-32+IWPSZ 
0046 50E8 BSS IWPSZ 
0047 50F8 IwP$l0 EQU $-32+IWPSZ 
0048 5100 BSS IWPSZ 
0049 ‘5110 <IWwP$l1l EQU $-32+IWPSZ — 
0050 5118 BSS IWPSZ 
0051 5128 IwPsl2 EQU $-32+IWPSZ 
0052 BSS 














0053 
0054 5148 
0055 
0056 5160 
0057 
0058 5178 
0059 5190 
0060 


CONFIG 
0061 

0062 

(¥ 0063 0000 


5140 


5158 


9170 


IWP$13 
IWPS$14 
IWPS15 


BADSWP 
* 


SDSMAC 3.3.0 


51B0 LOWHP EQU §$ 
* 


EQU 
BSS 
EQU 
BSS 
EQU 
BSS 
BSS 
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IWPSZ A 4. ee 
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